J'expérimente avec le développement piloté par les tests et j'ai constaté que j'arrive souvent à la situation suivante:

1. J'écris des tests pour certaines fonctionnalités X. Ces tests échouent.
2. En essayant d'implémenter X, je vois que j'ai besoin d'implémenter une fonctionnalité Y dans une couche inférieure de mon code. Donc...
3. J'écris des tests pour Y. Maintenant, les deux tests pour X et Y échouent.

Une fois, j'avais 4 fonctionnalités dans différentes couches de code travaillées en même temps, et je perdais ma concentration sur ce que je fais réellement (trop de tests échouant en même temps).

Je pense que je pourrais résoudre ce problème en mettant plus d'efforts dans la planification de mes tâches avant même de commencer à écrire des tests. Mais dans certains cas, je ne savais pas que je devrais aller plus loin, parce que, par exemple, je ne connaissais pas très bien l'API de la couche inférieure.

Que dois-je faire dans de tels cas? TDD a-t-il des recommandations?

La bonne chose est que vous réalisez que votre code sous test a besoin d'aide. Plutôt que de l'implémenter immédiatement, créez une interface et utilisez des simulateurs pour vous assurer que vos tests marquent le bon code. Après avoir réussi ces tests, vous pouvez ensuite passer à l'implémentation du code sur lequel il s'appuie.

Les talons et les maquettes peuvent être utilisés pour simuler la fonctionnalité qui n'est pas encore modifiée / implémentée. Ils peuvent également vous aider à résoudre les dépendances qui provoquent ce type de «réaction en chaîne».

D'un autre côté, la meilleure approche consiste peut-être à ne conserver qu'un seul test (qui échoue) à l'origine du changement suivant.

D'autres tests qui ciblent le code qui repose sur de nouvelles fonctionnalités peuvent être temporairement désactivés car ils ne sont pas vraiment pertinents à ce stade, c'est-à-dire. dans votre cas, désactivez les tests pour X jusqu'à ce que vous implémentiez Y, etc.

De cette façon, vous pouvez vous concentrer sur le prochain changement uniquement, ce qui est ce que vous voulez, je pense.

Arrêtez

À première vue, il semble qu'il puisse y avoir deux problèmes distincts ici:

1. vous avez oublié des histoires et des scénarios de test et ne les avez pas découverts avant de commencer à travailler sur un scénario de test particulier, et / ou

2. vous êtes en train de faire des tests unitaires, et non TDD fonction test

Pour # 1, arrêtez , revenez en arrière et mettez à jour les histoires et les scénarios de test, puis recommencez avec un scénario différent.

Pour # 2, arrêtez -vous et rappelez-vous que vous testez des fonctionnalités, pas des unités, alors utilisez des simulateurs pour masquer d'autres interfaces et / ou implémentez plus de code pour réussir le test sans ajouter de nouveaux scénarios de test. Cela suppose que vous ne manquez pas de scénarios de test, mais que vous êtes plutôt - et cela est vraiment courant - en combinant les tests unitaires et TDD.

C'est une grande question et une énorme frustration pour moi aussi avec TDD. J'ai l'impression que TDD manque dans ce scénario où vous n'avez tout simplement aucun moyen de savoir de quels composants ou fonctionnalités de niveau inférieur vous aurez besoin jusqu'à ce que vous commenciez à développer.

Personnellement, j'ai trouvé que TDD ne fonctionne que si vous savez exactement ce que vous devez faire et ce que vous devez appeler pour exécuter une fonction. Les développeurs ne savent pas toujours tout avant de commencer, j'ai donc trouvé que la meilleure façon pour moi d'atténuer la situation même que vous décrivez:

Prototype

Lorsque je crée de simples applications prototypes pour explorer et découvrir des méthodes et des approches à un problème technique, je découvre une grande partie du travail sur les jambes et élimine ces recherches avant de commencer. La conception et l'estimation deviennent également beaucoup plus faciles.

Si le prototype doit être si impliqué qu'il devient l'application, je vous exhorte cependant à ne pas faire la chose paresseuse et à construire des tests unitaires pour votre prototype après coup.

À ce stade, vous devez en savoir plus sur l'API de niveau inférieur et être en mesure de simuler avec succès l'API de niveau inférieur dans vos composants de niveau supérieur.

Cela dépend du type de tests que vous écrivez en faisant TDD.

Le modèle classique consiste à écrire des tests unitaires et à utiliser des simulations ou des talons pour dissocier le test des autres "unités" de code.

Il existe de nombreux autres modèles alternatifs tels que ATDD où le test d'une pile complète, ou un test de pile presque complète. Dans ce cas particulier, vos tests d'écriture qui affirment le comportement du programme requis ne constituent pas une seule unité de code, vous n'écrirez donc pas d'autres tests. Vous obtiendrez la mise en œuvre de l'aller-retour pour satisfaire le test. Vous ajoutez ensuite d'autres tests pour d'autres fonctionnalités / comportements.