TDD: Que se passe-t-il avant le premier test unitaire?

Je comprends surtout la théorie du TDD, mais je n'arrive pas à comprendre comment commencer. Je m'assois pour écrire un test unitaire pour un projet personnel et réaliser. . . Je n'ai aucune idée de ce que je teste. Quels objets, quelles fonctionnalités, etc.

Par exemple, disons que je veux écrire une application pour aider notre famille à gérer les tâches de corvée. Voici quelques questions dans mon esprit: comment passer de cette idée à mon premier test? Combien faut-il décider avant de commencer et combien dois-je déterminer après avoir commencé à écrire des tests? Quand dois-je prendre des décisions telles que le stockage des données dans un fichier texte ou une base de données? Dois-je subir des tests d'acceptation des utilisateurs avant de commencer? Dois-je faire concevoir l'interface utilisateur? Dois-je avoir une spécification? (Je me rends compte qu'au moins certaines de ces questions d'exemple sont probablement dans une "zone grise").

En plus de la question du titre sur le premier test unitaire, pourriez-vous également donner un exemple de ce à quoi pourrait ressembler le premier test unitaire d'un projet comme l'exemple de projet?

J'aime commencer par une liste de fonctionnalités, et pour chaque fonctionnalité, écrire les histoires d'utilisateurs, puis pour chaque histoire, écrire des descriptions de test.

Réfléchissez un peu à la conception, puis choisissez une description de test et commencez à coder: refactor rouge-vert.

Répétez jusqu'à ce que tous les tests réussissent.

Oui, les tests d'acceptation doivent être considérés comme faisant partie de cela, attachés à l'histoire appropriée.

Vous avez découvert dès le début comment TDD concerne le design . Avant d'écrire votre premier test, vous devez penser à ce que sera votre premier élément de fonctionnalité et à quoi ressemblerait votre programme si cette fonctionnalité fonctionnait.

Les développeurs qui n'utilisent pas TDD doivent également y penser - mais ils peuvent "simplement plonger" et commencer à écrire quelque chose, n'importe quoi. Mais «quelque chose, n'importe quoi» n'est pas toujours sur la voie de la prestation du programme que vous pensiez mettre en place. Quel est? Eh bien, à quoi ressemblerait votre programme s'il fonctionnait? Quels tests réussiraient-ils?

Je veux écrire une application pour aider notre famille à gérer les tâches de corvée.

Cool. Si cette application fonctionnait, que ferait-elle? Eh bien, une corvée pourrait probablement être assignée à une personne, non?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

Il y a un début. Pas l'endroit où vous devez commencer, pas nécessairement le meilleur endroit pour commencer - mais c'est un endroit. C'est quelque chose que vous voulez que votre code prenne en charge (même si je suis sûr que vous pouvez trouver de meilleurs noms). Commencez par là, regardez-le échouer. Faites-le passer. Nettoie ça. Faire mousser, rincer, répéter.

Oui, TDD a ce problème. C'est pourquoi je recommande maintenant le développement axé sur le comportement.

Démarrez manuellement. Écrivez quelque chose de similaire à une histoire d'utilisateur:

• En tant qu'utilisateur
• Lorsque je sélectionne Ajouter au panier, je souhaite que le produit soit ajouté de manière transparente en arrière-plan
• Pour que je puisse continuer mon expérience d'achat sans interruption

Maintenant, quelles sont les fonctionnalités qui soutiennent cet objectif (la partie «Alors ça»)?

• Lorsqu'un article est ajouté au panier
  • Le panier d'achat pour l'utilisateur contiendra le nouvel article
  • Le nombre total d'articles dans le panier augmentera d'une unité
  • L'utilisateur ne doit pas être redirigé
  • Une option de départ sera disponible
• Lorsqu'il y a deux articles dans le panier et que l'utilisateur choisit de payer
  • L'utilisateur sera redirigé vers la page de paiement
  • Les deux éléments seront visibles

Ce sont toutes des choses que vous pouvez et devez vérifier manuellement.

Faites cela pendant un petit moment. Ensuite, comme un bon développeur, commencez à chercher des moyens d'automatiser les pièces redondantes. Cela variera en fonction de votre plate-forme, mais la plupart ont des cadres décents disponibles.

.Net a WatiN pour automatiser la page Web ou, si vous voulez tester une API, je recommanderais l'ajout de Subspec à xUnit ou MSpec (vous pouvez également le faire avec n'importe quel framework de test, juste ceux qui facilitent le nom de vos tests d'une manière qui soutient ce style de pensée).

Ruby a du concombre pour les tests d'automatisation et rspec pour les tests d'API de niveau inférieur

Javascript a jasmin et qUnit.

point point point

Comment passer de cette idée à mon premier test? Combien faut-il décider avant de commencer et combien dois-je déterminer après avoir commencé à écrire des tests?

Décomposez votre application en petites histoires. ("En tant qu'utilisateur, je veux double-cliquer sur une icône et lancer le programme." Ou "En tant qu'utilisateur, je veux ouvrir mon navigateur et accéder au programme." Peu importe.)

Décomposez ensuite l'histoire en quelques tâches. (par exemple, créer un projet dans Eclipse, configurer un référentiel de code) Lorsque vous arrivez à une tâche de codage, écrivez votre premier test.

Quand dois-je prendre des décisions telles que le stockage des données dans un fichier texte ou une base de données?

Si vous n'êtes pas sûr, choisissez celui qui vous semble le plus simple et faites-le. (probablement le fichier texte) Si vous vous rendez compte que vous avez fait une erreur, refactorisez. Si vos tests sont bien structurés, vous devriez être en mesure de modifier le back-end et d'attraper les effets secondaires imprévus qui surviennent.

Je suis surpris qu'aucune des réponses ne mentionne la chose que vous faites avant d'écrire votre premier test, qui consiste à créer une liste de tests . Une liste de tests est informée par les phases de rédaction et de conception de l'histoire mentionnées dans d'autres réponses et est le précurseur direct de la rédaction d'un test que vous semblez rechercher.

Pour plus d'informations sur TDD, je recommanderais le développement piloté par l'exemple par Kent Beck. Il a également un screencast TDD qui suit le développement d'une bibliothèque non triviale dans un pur style TDD avec des explications de Kent à chaque étape du processus. Je pense que c'est un excellent exemple de TDD dans la pratique, même s'il est (par nécessité) fait dans un environnement artificiel.

Avant le premier test unitaire, vous pensez à ce que vous voulez faire, puis réfléchissez à la façon dont vous le testeriez. Ensuite, écrivez ce test, voyez-le échouer et implémentez du code pour le faire passer.

Rincer, répéter, etc.

Pour moi, c'est la réflexion sur la façon dont vous le testeriez qui est importante et c'est ce qui peut guider votre conception.