Qu'est-ce que le développement piloté par les tests (TDD) ? Exemple

Qu'est-ce que le développement piloté par les tests (TDD) ?

Développement piloté par les tests (TDD) est une approche de développement logiciel dans laquelle des cas de tests sont développés pour spécifier et valider ce que le code fera. En termes simples, les cas de test pour chaque fonctionnalité sont d'abord créés et testés et si le test échoue, le nouveau code est écrit afin de réussir le test et de rendre le code simple et sans bug.

Le développement piloté par les tests commence par la conception et le développement de tests pour chaque petite fonctionnalité d'une application. Le framework TDD demande aux développeurs d'écrire du nouveau code uniquement si un test automatisé a échoué. Cela évite la duplication de code. La forme complète TDD est un développement piloté par les tests.

Le concept simple de TDD est d'écrire et de corriger les tests ayant échoué avant d'écrire du nouveau code (avant le développement). Cela permet d'éviter la duplication de code car nous écrivons une petite quantité de code à la fois afin de réussir les tests. (Les tests ne sont rien d'autre que des conditions requises que nous devons tester pour les remplir).

Le développement piloté par les tests est un processus de développement et d'exécution de tests automatisés avant le développement réel de l'application. Par conséquent, TDD est parfois aussi appelé Testez le premier développement.

Comment effectuer le test TDD

Les étapes suivantes définissent comment effectuer le test TDD,

Ajoutez un test.
Exécutez tous les tests et voyez si un nouveau test échoue.
Écrivez du code.
Exécutez des tests et refactorisez le code.
Répéter.

Effectuer un test TDD — Cinq étapes du développement piloté par les tests

Le cycle TDD définit

Écrire un test
Faites-le fonctionner.
Changez le code pour le rendre correct, c'est-à-dire Refactor.
Répétez le processus.

Quelques précisions sur TDD :

L'approche TDD ne concerne ni le « Test », ni la « Conception ».
TDD ne signifie pas « écrire certains tests, puis construire un système qui réussit les tests ».
TDD ne signifie pas « faire beaucoup de tests ».

TDD contre. Tests traditionnels

Vous trouverez ci-dessous la principale différence entre le développement piloté par les tests et les tests traditionnels :

L'approche TDD est avant tout une technique de spécification. Il garantit que votre code source est minutieusement testé au niveau de la confirmation.

Avec les tests traditionnels, un test réussi détecte un ou plusieurs défauts. C'est la même chose que TDD. Lorsqu’un test échoue, vous avez progressé car vous savez que vous devez résoudre le problème.
TDD garantit que votre système répond réellement aux exigences définies pour celui-ci. Cela aide à renforcer votre confiance dans votre système.
Dans TDD, l'accent est davantage mis sur le code de production qui vérifie si les tests fonctionneront correctement. Dans les tests traditionnels, l’accent est davantage mis sur la conception des cas de test. Si le test montrera l'exécution correcte/mauvaise de l'application afin de répondre aux exigences.
En TDD, vous réalisez un test de couverture à 100 %. Chaque ligne de code est testée, contrairement aux tests traditionnels.
La combinaison des tests traditionnels et du TDD conduit à l'importance de tester le système plutôt que de le perfectionner.
In Modélisation Agile (AM), vous devriez « tester dans un but précis ». Vous devez savoir pourquoi vous testez quelque chose et à quel niveau il doit être testé.

Qu'est-ce que l'acceptation TDD et le développeur TDD

Il existe deux niveaux de TDD

Acceptation TDD (ATDD) : Avec ATDD, vous écrivez un seul test d'acceptation. Ce test répond aux exigences de la spécification ou satisfait au comportement du système. Après cela, écrivez juste assez de code de production/fonctionnalité pour réaliser ce test d'acceptation. Le test d'acceptation se concentre sur le comportement global du système. ATDD était également connu sous le nom de Développement axé sur le comportement (BDD).
Développeur TDD : Avec Developer TDD, vous écrivez un test de développeur unique, c'est-à-dire un test unitaire, puis juste assez de code de production pour effectuer ce test. Le test unitaire se concentre sur chaque petite fonctionnalité du système. Le développeur TDD est simplement appelé comme TDD.L'objectif principal d'ATDD et de TDD est de spécifier des exigences détaillées et exécutables pour votre solution sur une base juste à temps (JIT). JIT signifie prendre en compte uniquement les exigences nécessaires dans le système. Augmentez donc l’efficacité.

Mise à l'échelle du TDD via le développement agile piloté par modèle (AMDD)

TDD est très doué pour la spécification et la validation détaillées. Il ne parvient pas à réfléchir à des problèmes plus importants tels que la conception globale, l’utilisation du système ou l’interface utilisateur. AMDD résout les problèmes de mise à l'échelle Agile que TDD ne résout pas.

Ainsi AMDD est utilisé pour des problèmes plus importants.

Le cycle de vie de l'AMDD

Dans le développement piloté par modèle (MDD), des modèles étendus sont créés avant l'écriture du code source. Lesquels ont à leur tour une approche agile ?

Dans la figure ci-dessus, chaque case représente une activité de développement.

La visualisation est l'un des processus TDD de tests de prédiction/imagination qui seront effectués au cours de la première semaine du projet. L'objectif principal de la visualisation est d'identifier la portée du système et l'architecture du système. Des exigences de haut niveau et une modélisation de l'architecture sont réalisées pour une visualisation réussie.

C'est le processus dans lequel non pas une spécification détaillée du logiciel/système est effectuée, mais l'exploration des exigences du logiciel/système qui définit la stratégie globale du projet.

Itération 0 : Visualisation

Il existe deux sous-activations principales.

Visualisation des besoins initiaux.Plusieurs jours peuvent être nécessaires pour identifier les exigences de haut niveau et la portée du système. L'objectif principal est d'explorer le modèle d'utilisation, le modèle de domaine initial et le modèle d'interface utilisateur (UI).
Initiales Archivision structurale. Il faut également plusieurs jours pour identifier l’architecture du système. Il permet de définir les orientations techniques du projet. L'objectif principal est d'explorer les diagrammes technologiques, le flux de l'interface utilisateur (UI), les modèles de domaine et les cas de changement.

Modélisation itérative

Ici, l'équipe doit planifier le travail qui sera effectué pour chaque itération.

Un processus agile est utilisé pour chaque itération, c'est-à-dire qu'à chaque itération, un nouvel élément de travail sera ajouté en priorité.
Les premiers travaux prioritaires seront pris en considération. Les éléments de travail ajoutés peuvent être redéfinis ou supprimés de la pile d'éléments à tout moment.
L'équipe discute de la manière dont elle va mettre en œuvre chaque exigence. La modélisation est utilisée à cet effet.
L'analyse et la conception de la modélisation sont effectuées pour chaque exigence qui va être mise en œuvre pour cette itération.

Prise d'assaut de modèles

Ceci est également connu sous le nom de modélisation juste à temps.

Ici, la séance de modélisation implique une équipe de 2/3 membres qui discutent des problèmes sur papier ou sur tableau blanc.
Un membre de l’équipe demandera à un autre de modéliser avec lui. Cette séance de modelage prendra environ 5 à 10 minutes. Où les membres de l’équipe se réunissent pour partager un tableau blanc/du papier.
Ils explorent les problèmes jusqu'à ce qu'ils ne trouvent pas la cause principale du problème. Juste à temps, si un membre de l'équipe identifie le problème qu'il souhaite résoudre, il demandera rapidement l'aide des autres membres de l'équipe.
D'autres membres du groupe explorent ensuite le problème, puis tout le monde continue comme avant. On l’appelle également modélisation debout ou sessions d’assurance qualité client.

Développement piloté par les tests (TDD)

Il favorise les tests de confirmation de votre code d'application et les spécifications détaillées.
Les tests d'acceptation (exigences détaillées) et les tests des développeurs (test unitaire) sont des entrées pour TDD.
TDD rend le code plus simple et clair. Cela permet au développeur de conserver moins de documentation.

Avis

Ceci est facultatif. Il comprend des inspections de code et des révisions de modèles.
Cela peut être fait pour chaque itération ou pour l’ensemble du projet.
C'est une bonne option pour donner votre avis sur le projet.

Développement piloté par les tests (TDD) vs. Développement agile piloté par modèle (AMDD)

TDD	AMDD
TDD raccourcit la boucle de rétroaction de la programmation	AMDD raccourcit la boucle de rétroaction de modélisation.
TDD est une spécification détaillée	AMDD fonctionne pour des problèmes plus importants
TDD favorise le développement de code de haute qualité	AMDD favorise une communication de haute qualité avec les parties prenantes et les développeurs.
TDD parle aux programmeurs	AMDD parle à Business Analyst, les parties prenantes et les professionnels des données.
TDD non orienté visuellement	AMDD visuellement orienté
TDD a une portée limitée aux travaux logiciels	L'AMDD a un large champ d'action incluant les parties prenantes. Cela implique de travailler vers une compréhension commune
Les deux soutiennent le développement évolutif	---------------

Cadres TDD

Voici la liste des meilleurs frameworks de développement piloté par les tests (TDD)

Junite
TestNG
csUnit et NUnit
Rspec

Maintenant, apprenons le développement piloté par les tests par l'exemple.

Exemple de TDD

Ici, dans cet exemple de développement piloté par les tests, nous définirons un mot de passe de classe. Pour ce cours, nous essaierons de satisfaire aux conditions suivantes.

Une condition pour l'acceptation du mot de passe :

Le mot de passe doit comporter entre 5 et 10 caractères.

Tout d'abord, dans cet exemple TDD, nous écrivons le code qui remplit toutes les exigences ci-dessus.

Scénario 1: Pour exécuter le test, nous créons la classe PasswordValidator ();

Nous exécuterons ci-dessus la classe TestPassword ();

La sortie est PASSÉE comme indiqué ci-dessous ;

Sortie:

Scénario 2: Ici, nous pouvons voir dans la méthode TestPasswordLength() qu'il n'est pas nécessaire de créer une instance de la classe PasswordValidator. Instance signifie créer un objet de classe pour référencer les membres (variables/méthodes) de cette classe.

Nous supprimerons la classe PasswordValidator pv = new PasswordValidator () du code. Nous pouvons appeler le est valable () méthode directement par Validateur de mot de passe. EstValide (« Abc123 »). (Voir l'image ci-dessous)

Nous refactorisons donc (modifions le code) comme ci-dessous :

Scénario 3: Après la refactorisation, la sortie affiche un statut d'échec (voir image ci-dessous), car nous avons supprimé l'instance. Il n'y a donc aucune référence à une méthode non statique est valable ().

Nous devons donc changer cette méthode en ajoutant le mot « statique » avant Boolean en tant que public static boolean isValid (String password). Refactoring Class PasswordValidator () pour supprimer l'erreur ci-dessus afin de réussir le test.

Sortie :

Après avoir apporté des modifications à la classe PassValidator (), si nous exécutons le test, la sortie sera RÉUSSIE comme indiqué ci-dessous.

Avantages du TDD

Voici les principaux avantages du développement piloté par les tests en génie logiciel :

Notification précoce des bogues.

Les développeurs testent leur code, mais dans le monde des bases de données, cela consiste souvent en des tests manuels ou en des scripts ponctuels. En utilisant TDD, vous construisez, au fil du temps, une suite de tests automatisés que vous et tout autre développeur pouvez réexécuter à volonté.

Code mieux conçu, plus propre et plus extensible.

Cela permet de comprendre comment le code sera utilisé et comment il interagit avec d'autres modules.
Il en résulte une meilleure décision de conception et un code plus maintenable.
TDD permet d'écrire du code plus petit ayant une seule responsabilité plutôt que des procédures monolithiques avec plusieurs responsabilités. Cela rend le code plus simple à comprendre.
TDD oblige également à écrire uniquement du code de production pour réussir les tests basés sur les besoins des utilisateurs.

Confiance pour refactoriser

Si vous refactorisez le code, il peut y avoir des possibilités de ruptures dans le code. Ainsi, en disposant d'un ensemble de tests automatisés, vous pouvez corriger ces pauses avant la sortie. Un avertissement approprié sera donné si des ruptures sont détectées lors de l'utilisation de tests automatisés.
L'utilisation de TDD devrait aboutir à un code plus rapide et plus extensible avec moins de bogues pouvant être mis à jour avec un minimum de risques.

Bon pour le travail d'équipe

En l’absence d’un membre de l’équipe, les autres membres de l’équipe peuvent facilement reprendre et travailler sur le code. Cela facilite également le partage des connaissances, rendant ainsi l’équipe globalement plus efficace.

Bon pour les développeurs

Bien que les développeurs doivent consacrer plus de temps à l'écriture des cas de test TDD, le débogage et le développement de nouvelles fonctionnalités prennent beaucoup moins de temps. Vous écrirez du code plus propre et moins compliqué.

Résumé

TDD signifie Développement piloté par les tests.
TDD signifiant : C'est un processus de modification du code afin de réussir un test conçu préalablement.
L'accent est davantage mis sur le code de production plutôt que sur la conception de cas de test.
Le développement piloté par les tests est un processus de modification du code afin de réussir un test conçu préalablement.
In Génie logiciel, On l'appelle parfois "Testez d'abord le développement."
Les tests TDD incluent la refactorisation d'un code, c'est-à-dire la modification/l'ajout d'une certaine quantité de code au code existant sans affecter le comportement du code.
Programmation TDD lorsqu'il est utilisé, le code devient plus clair et simple à comprendre.

Tu pourrais aimer: