Approche de développement test-drive pour le développement logiciel agile

Maintenant, les gens parlent souvent de développement agile.

Qu’est-ce que le développement agile ?

Le développement agile  est une capacité de développement logiciel qui répond à des besoins en évolution rapide. Leurs noms, concepts, processus et terminologie spécifiques varient. Par rapport aux « non agiles », ils mettent l’accent sur une collaboration étroite entre les équipes de programmeurs et les experts métier, la communication en face à face (considérée comme plus efficace que la documentation écrite), et livrent fréquemment de nouvelles versions de logiciels, des équipes petites et  auto-organisées  pour les petites équipes. et des approches d’écriture de fonctionnalités utiles et d’organisation d’équipe qui s’adaptent à l’évolution des besoins, en mettant davantage l’accent sur le rôle des personnes dans le développement de logiciels.

Cependant, il existe plusieurs versions similaires des méthodes de développement agiles TDD, telles que TDD : BDD, DDD et ATDD. Permettez-moi de présenter brièvement ces méthodes avant de présenter TDD en détail :

TDD : développement piloté par les tests

Le développement piloté par les  tests (TDD) est un processus de développement logiciel qui repose sur la transformation des exigences logicielles en cas de test avant que le logiciel ne soit entièrement développé, et sur le suivi de tout le développement logiciel en testant à plusieurs reprises le logiciel pour tous les cas de test. C’est le contraire de développer d’abord un logiciel, puis de créer des cas de test. Certains modèles populaires prennent très bien en charge TDD, tels que MVC et  MVP .

BDD : Développement axé sur le comportement (Behavior Driven Development)

Le développement piloté par le comportement (BDD) est également un processus de développement logiciel agile. Il encourage la collaboration entre les développeurs, les testeurs d’assurance qualité et les représentants des clients dans les projets logiciels. Il encourage les équipes à utiliser des conversations et des exemples concrets pour formaliser une compréhension commune du fonctionnement de l’application. Il vient du développement piloté par les tests (TDD).

ATDD : développement piloté par les tests d’acceptation

Afin de promouvoir la réalisation de code fonctionnel par le biais de cas de tests unitaires, l’équipe doit définir les normes de qualité et les règles d’acceptation attendues, et promouvoir la pratique TDD des développeurs et les performances des testeurs grâce à un plan de test d’acceptation clair et cohérent (comprenant une série de tests scénarios). Pour les développeurs, il met l’accent sur la manière de mettre en œuvre le système et de le tester.

DDD : Conception de lecteur de domaine

DDD fait référence à la conception pilotée par le domaine, c’est-à-dire au développement piloté par le domaine. DDD est en fait construit sur cette base car il se concentre sur la conception de la couche de service, se concentre sur la mise en œuvre commerciale, combine l’analyse et la conception, et ne le maintient plus dans un état divisé, afin de mettre en œuvre correctement et complètement les besoins des clients et de construire un modèle d’entreprise. évolutivité.

Plan de mise en œuvre du TDD

Grâce à des tests pour promouvoir l’ensemble du développement, mais le développement piloté par les tests n’est pas simplement un simple travail de test, mais un processus de quantification de l’analyse des exigences, de la conception et du contrôle de la qualité.

Principes de développement

Écrivez d’abord le code de test, puis écrivez le code de la fonction.

1. Écrire le code de test conformément au document d’exigences, et non pour réaliser la fonction ;
2. Je ne veux pas grossir d’une bouchée. Lorsque vous testez de grands blocs fonctionnels, vous devez d’abord les diviser en blocs fonctionnels plus petits pour les tests ;
3. N’oubliez pas de ne pas écrire de code pour compléter la fonction, utilisez le code le plus simple possible pour implémenter la fonction ;
4. Si les exigences peuvent être testées, écrivez du code de test et abandonnez celles qui ne peuvent pas être testées ou pensez qu’elles n’ont pas besoin d’être testées ;
5. Avant de modifier/d’ajouter un code de fonction, vous devez d’abord déterminer si vous souhaitez modifier/ajouter des cas de test ;
6. Code de fonction/test, structure déraisonnable, code en double, etc., refactoriser dans le temps après la réussite du test.

Processus de développement TDD

1. Analyser et déterminer un scénario de test cible ;
2. Ajouter un test unitaire pour vérifier l’entrée et la sortie du scénario de test ;
3. Exécutez le test et obtenez le résultat du test d’échec ;
4. Écrivez le code de fonction le plus simple pour réussir le test ;
5. Exécutez à nouveau le test et vérifiez que le test réussit ;
6. Effectuer la refactorisation du code, y compris le code fonctionnel et le code de test unitaire ;
7. Répétez les étapes ci-dessus jusqu’à ce que le développement soit terminé.

Avantages du TDD

1. Réduisez la charge des développeurs . Grâce à un processus clair, concentrons-nous sur un seul point à la fois, et le fardeau de la réflexion est moindre.
2. Le filet de protection . La couverture des tests unitaires complets fournit un filet de protection pour le code produit, ce qui permet de répondre facilement aux changements d’exigences ou d’améliorer la conception du code. Ainsi, si les exigences de votre projet sont stables, réalisées en une fois et qu’il n’y a pas de modifications ultérieures, les avantages de TDD sont moindres.
3. Clarifier les exigences à l’avance . Rédiger des tests en premier peut nous aider à réfléchir aux exigences et à clarifier les détails des exigences à l’avance, plutôt que de découvrir des exigences peu claires seulement à mi-parcours du code.
4. Rétroaction rapide . Beaucoup de gens disent que lorsque TDD, mon volume de code augmente, donc l’efficacité du développement diminue. Cependant, si vous n’avez pas de tests unitaires, vous devez les tester manuellement, vous passez beaucoup de temps à préparer des données, à lancer des applications, à modifier des interfaces, etc., et les retours sont lents. Pour être précis, un retour rapide est un avantage des tests unitaires.