Le test du backend d'une application Web est un élément essentiel du processus de développement et de toute surveillance continue. Consultez également les tests de l'interface.
Développement basé sur les tests
Dans le développement basé sur les tests (TDD), les exigences de l'application sont traduites en scénarios de test avant sa mise en œuvre complète. Pendant le développement, ces tests sont écrits en premier, puis mis en œuvre successivement au fur et à mesure de la création de l'application. Des exigences claires (c'est-à-dire des scénarios de test) garantissent que le code final est bien structuré, répond à toutes les exigences et est correct, ce qui est particulièrement important dans les premières étapes du développement.
Intégration continue et tests automatisés
Les tests d'intégration continue (CI) effectuent automatiquement des tests sur toute modification de code, par exemple lors de la revue de code ou lorsque du code a été fusionné dans votre dépôt de code. Les tests automatisés améliorent la qualité globale et la confiance dans le code envoyé en réduisant les risques de défaillance ou de régression pendant le développement. Nous vous recommandons de configurer un système de test automatisé pour votre environnement afin de garantir l'état de votre application. Utilisez un système compatible avec votre architecture, votre plate-forme et votre langage, et parfaitement intégré à votre pipeline de développement. Par exemple, utilisez GitHub Actions pour un workflow d'intégration continue ou un pipeline de CI personnalisé intégré dans le cloud et adapté à votre configuration.
Découvrez les principes des tests automatisés et comment améliorer vos tests. Apprenez-en plus sur les tests d'intégration continue et les bonnes pratiques pour implémenter, configurer et mesurer vos performances.
L'étape suivante consiste à utiliser un pipeline de livraison continue (CD) automatisé pour déployer automatiquement les modifications et les mises à jour dans votre application.
Tests unitaires
Les tests unitaires font référence au test isolé de petites parties de code autonomes. Utilisez un framework de tests unitaires recommandé et connu pour votre langage ou framework de backend. Par exemple, pour une application monolithique basée sur Java, utilisez JUnit. Pour une application sans serveur basée sur JavaScript (y compris Dart ou TypeScript), utilisez un framework conçu pour les tests JavaScript, tel que Jest.
La plupart des frameworks de backend modernes disposent de ressources dédiées aux tests. Envisagez d'intégrer ces fonctionnalités à votre pipeline d'intégration continue (CI) pour automatiser les tests. Assurez-vous que vos tests unitaires fournissent une bonne couverture de code de votre application. La plupart des frameworks de test fournissent des fonctionnalités permettant d'analyser la couverture de vos tests, de créer des rapports la concernant et de permettre l'intégration dans votre pipeline de compilation.
Tests d'intégration
Les tests d'intégration font référence au test combiné de modules plus volumineux ou de parties plus importantes de votre application. Par rapport aux tests unitaires (qui se concentrent sur des parties individuelles du code), les tests d'intégration se concentrent sur l'intégration de parties individuelles de votre architecture. Cela peut également inclure des flux de bout en bout couvrant plusieurs étapes et modules à travers l'application.
Les tests d'intégration peuvent couvrir différents modules de votre application pouvant nécessiter une interaction avec des services externes, tels que le stockage de données, les systèmes de fichiers ou les paiements. Envisagez de structurer votre application de sorte qu'elle accepte les abstractions pour ces services via l'injection de dépendances ou des fonctionnalités similaires fournies par votre framework backend.
Tests de comportement et de fonctionnement
En plaçant le backend (ou les modules ou composants individuels) comme une boîte opaque, les tests fonctionnels se concentrent sur l'entrée et la sortie du système. Bien que les tests comportementaux puissent être plus courants pour l'interface, ils jouent également un rôle essentiel pour confirmer l'intégrité de bout en bout d'un système backend. Ces types de tests confirment que le système réagit et se comporte comme prévu pour différentes entrées.
Tests de régression
Les tests de régression font référence à des tests qui confirment que l'application se comporte toujours comme prévu. Les tests terminés précédemment sont réexécutés pour toute nouvelle modification afin de garantir que les modifications n'ont pas réintroduit de problèmes précédents. À mesure que les bugs sont corrigés dans une application, des tests unitaires ou d'intégration doivent être ajoutés pour éviter qu'ils ne se reproduisent. Les tests de régression doivent être intégrés au pipeline de test et de compilation habituel.
Test de fumée
Les tests de fumée, également appelés tests de vérification de build, se concentrent sur la vérification des fonctions les plus critiques de votre application backend. Au-delà des tests d'intégration, qui excluent certaines fonctionnalités et dépendances externes, les tests de fumée couvrent les cas d'utilisation critiques de votre application. Les tests de fumée peuvent servir de couche de vérification supplémentaire avant la promotion d'une application dans l'environnement de préproduction afin de garantir un comportement précis. Les tests de fumée peuvent consister en des tests unitaires automatisés ou des tests fonctionnels manuels menés par une équipe de contrôle qualité.
Environnements de production et de préproduction
Un environnement de préproduction est une copie de votre environnement de production, placée en bac à sable pour faciliter les tests. Un déploiement dédié réduit le risque de problèmes avec l'environnement de production et facilite l'assurance qualité. L'environnement de préproduction vous permet de tester un système à proximité de l'environnement de production réel.
Il n'est pas toujours possible d'avoir une copie 1 pour 1 de l'environnement de production en raison de facteurs tels que le coût ou la complexité de l'architecture backend. Déterminez quelles parties du backend sont les plus critiques et optimisez-les pour un environnement de préproduction.
Les tests sur des données utilisées en production sont très avantageux pour tester le comportement de l'application avec des données réelles. Veillez à prendre en compte les implications en termes de confidentialité et à vos besoins en stockage de données pour un tel environnement de préproduction, et concevez soigneusement les données utilisées par votre système backend. L'accès à un tel environnement doit être étroitement contrôlé, en particulier si des données de production sont utilisées.
Tenez compte de l'échelle de votre système et déterminez si un environnement permanent est approprié pour votre application. Les environnements de préproduction progressifs qui peuvent être déployés automatiquement via un système de livraison continue offrent également des opportunités supplémentaires de tester des builds quotidiens ou hebdomadaires et de leur accorder un examen supplémentaire avant la publication.
Une autre approche consiste à s'appuyer davantage sur des tests d'intégration continue et des systèmes automatisés que sur un environnement de préproduction entièrement déployé. Tenez compte du workflow de votre équipe, de l'état du système, de la couverture du code et des exigences techniques.