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

Table des matières:

Anonim

Développement piloté par les tests

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

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

Le concept simple de TDD est d'écrire et de corriger les tests qui ont échoué avant d'écrire un nouveau code (avant le développement). Cela permet d'éviter la duplication de code lorsque 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 d'exigence 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 également appelé Test First Development.

Dans ce tutoriel, vous en apprendrez plus sur-

  • Comment effectuer un test TDD
  • TDD contre. Test traditionnel
  • Qu'est-ce que l'acceptation TDD et Developer TDD
  • Mise à l'échelle du TDD via le développement basé sur un modèle agile (AMDD)
  • Développement piloté par les tests (TDD) vs. Développement basé sur un modèle agile (AMDD)
  • Exemple de TDD
  • Avantages du TDD

Comment effectuer un test TDD

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

  1. Ajoutez un test.
  2. Exécutez tous les tests et voyez si un nouveau test échoue.
  3. Écrivez du code.
  4. Exécutez des tests et du code Refactor.
  5. Répéter.

Le cycle TDD définit

  1. Rédiger un test
  2. Faites-le courir.
  3. Modifiez le code pour le rendre correct, c'est-à-dire Refactor.
  4. Répétez le processus.

Quelques clarifications sur TDD:

  • TDD ne concerne ni le «test» ni le «design».
  • TDD ne signifie pas «écrire certains des tests, puis construire un système qui réussit les tests.
  • TDD ne signifie pas «faire beaucoup de tests».

TDD contre. Test traditionnel

L'approche TDD est avant tout une technique de spécification. Il garantit que votre code source est soigneusement testé au niveau de 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 lui. 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 fonctionnent 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 / incorrecte de l'application afin de répondre aux exigences.
  • Dans TDD, vous obtenez un test de couverture de 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 la perfectionner.
  • Dans la modélisation agile (AM), vous devez «tester avec un objectif». Vous devez savoir pourquoi vous testez quelque chose et à quel niveau il doit être testé.

Qu'est-ce que l'acceptation TDD et Developer TDD

Il existe deux niveaux de TDD

  1. Acceptation TDD (ATDD): Avec ATDD, vous écrivez un seul test d'acceptation. Ce test satisfait à l'exigence de la spécification ou satisfait au comportement du système. Après cela, écrivez juste assez de code de production / fonctionnalité pour remplir 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 Behavioral Driven Development (BDD).
  2. Developer 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 remplir ce test. Le test unitaire se concentre sur chaque petite fonctionnalité du système. Le développeur TDD est simplement appelé 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 ne prendre en compte que les exigences nécessaires dans le système. Alors augmentez votre efficacité.

Mise à l'échelle du TDD via le développement basé sur un modèle agile (AMDD)

TDD est très bon 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 fait pas.

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

Le cycle de vie d'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 prédiction / d'imagination des tests 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. La modélisation des exigences et de l'architecture de haut niveau est effectuée pour une vision réussie.

C'est le processus dans lequel on ne fait pas une spécification détaillée du logiciel / système mais en explorant les exigences du logiciel / système qui définit la stratégie globale du projet.

  1. Itération 0: visualisation

Il existe deux sous-activations principales.

  1. Prévision des besoins initiaux.

    L'identification des exigences de haut niveau et de la portée du système peut prendre plusieurs jours. 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).

  2. Visualisation architecturale initiale.

    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.

  1. Modélisation d'itération:

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

  • Le processus Agile est utilisé à chaque itération, c'est-à-dire qu'à chaque itération, un nouvel élément de travail sera ajouté avec 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 sera mise en œuvre pour cette itération.
  1. Modèle d'assaut:

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

  • Ici, la session de modélisation implique une équipe de 2/3 membres qui discutent des problèmes sur papier ou tableau blanc.
  • Un membre de l'équipe demandera à un autre de modéliser avec eux. Cette séance de modélisation prendra environ 5 à 10 minutes. Où les membres de l'équipe se réunissent pour partager un tableau blanc / 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 prendra rapidement l'aide d'autres membres de l'équipe.
  • Les autres membres du groupe explorent ensuite le problème, puis tout le monde continue comme avant. Il est également appelé modélisation stand-up ou sessions d'assurance qualité client.
  1. Développement piloté par les tests (TDD).
  • Il favorise les tests de confirmation de votre code d'application et des spécifications détaillées.
  • Le test d'acceptation (exigences détaillées) et les tests du développeur (test unitaire) sont des entrées pour le TDD.
  • TDD rend le code plus simple et clair. Cela permet au développeur de conserver moins de documentation.
  1. Commentaires.
  • Ceci est facultatif. Il comprend des inspections de code et des revues de modèles.
  • Cela peut être fait pour chaque itération ou pour l'ensemble du projet.
  • C'est une bonne option pour donner des commentaires sur le projet.

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

TDD AMDD
  • TDD raccourcit la boucle de retour de programmation
  • AMDD raccourcit la boucle de rétroaction de la modélisation.
  • TDD est une spécification détaillée
  • AMDD fonctionne pour des problèmes plus importants
  • TDD favorise le développement d'un code de haute qualité
  • AMDD favorise une communication de haute qualité avec les parties prenantes et les développeurs.
  • TDD parle aux programmeurs
  • AMDD s'entretient avec des analystes commerciaux, des parties prenantes et des professionnels des données.
  • TDD non orienté visuellement
  • AMDD visuellement orienté
  • TDD a une portée limitée aux travaux logiciels
  • AMDD a un large périmètre, y compris les parties prenantes. Il s'agit de travailler à une compréhension commune
  • Les deux soutiennent le développement évolutif
 --------------------------------------------

Exemple de TDD

Ici, dans cet exemple, nous allons définir un mot de passe de classe. Pour cette classe, nous essaierons de satisfaire les conditions suivantes.

Une condition pour l'acceptation du mot de passe:

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

Tout d'abord, nous écrivons le code qui remplit toutes les conditions ci-dessus.

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

Nous allons exécuter au-dessus de 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 la méthode isValid () directement par PasswordValidator. IsValid ("Abc123") . (Voir l'image ci-dessous)

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

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

Nous devons donc changer cette méthode en ajoutant un mot "statique" avant Boolean en tant que booléen statique public isValid (String password). Refactoring de la classe PasswordValidator () pour supprimer l'erreur ci-dessus pour réussir le test.

Production:

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

Avantages de TDD

  • Notification de bogue précoce.

    Les développeurs testent leur code, mais dans le monde des bases de données, cela consiste souvent en des tests manuels ou des scripts ponctuels. En utilisant TDD, vous créez, 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 aide à comprendre comment le code sera utilisé et comment il interagit avec les 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 responsabilité unique plutôt que des procédures monolithiques avec des responsabilités multiples. Cela rend le code plus simple à comprendre.
    • TDD oblige également à n'écrire que du code de production pour réussir les tests en fonction des besoins des utilisateurs.
  • Confiance pour refactoriser
    • Si vous refactorisez le code, il peut y avoir des possibilités de coupures dans le code. Ainsi, avec un ensemble de tests automatisés, vous pouvez corriger ces pauses avant la publication. Un avertissement approprié sera donné si des pauses 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 de tout membre de l'équipe, les autres membres de l'équipe peuvent facilement récupérer et travailler sur le code. Cela facilite également le partage des connaissances, ce qui rend l'équipe plus efficace dans l'ensemble.

  • Bon pour les développeurs

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

Résumé:

  • TDD signifie développement piloté par les tests. C'est un processus de modification du code afin de passer un test conçu précédemment.
  • Il met davantage l'accent sur le code de production 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écédemment.
  • En génie logiciel, on l'appelle parfois «Test First Development».
  • TDD inclut 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.
  • TDD lorsqu'il est utilisé, le code devient plus clair et simple à comprendre.

Cet article est contribué par Kanchan Kulkarni