Peut Fake It ('Til You Make It) TDD existe sans Triangulation en Real?

Question

Je pensais une fois que je 'fausse' ma mise en œuvre pour faire un test, jusqu'à quelle heure je devrais quitter cette fausse implémentation sans la changer avec l'implémentation REAL.

Si le TDD concerne le RED-GREEN-REFACTORING; et si j'arrive à VERT en faisant semblant,

• dois-je implémenter l'implémentation évidente juste après? OU devrais-je attendre qu'un nouveau test appelle cette implémentation fictive et échoue parce qu'il ne se comporte pas comme prévu? (Ce qui ressemble à un triangulation selon moi)

Ma question est la suivante:

Can Fake It ('Till You Make It!) Test modèle entraîné existe sans (deliberat ou indeliberate) triangulation?

Merci!

Answer 1

Vous avez discuté de choses similaires au travail. Mon avis est qu'un test d'unité est juste qu'il teste une petite unité où ses dépendances sont des simulacres ou des talons afin que vous puissiez brancher quelques données afin d'affirmer vos attentes.

Bien sûr, cela m'amène à savoir quand implémenter réellement mes interfaces et, plus important encore, comment puis-je savoir que la fichue chose fonctionne. C'est là qu'interviennent les tests d'intégration ou les tests BDD. Quand j'écris un article ou une histoire particulière, j'essaie d'étoffer un test BDD qui traverse le système, ces tests doivent utiliser toutes les implémentations réelles jusqu'aux limites externes. J'essaie d'utiliser le même câble IoC dans les tests que celui utilisé dans l'application réelle. Une fois que ce test a été étoffé et est rouge, vous pouvez commencer à plonger à vos tests unitaires et le câblage de la chose ensemble. Lorsque vous avez terminé votre test BDD devrait passer. La bonne chose à propos des tests BDD est que vous pouvez changer certaines parties des composants internes mais tant que vous ne changez pas vos exigences, le test reste pour l'essentiel inchangé.

Je ai joué avec StoryQ pour les tests BDD et le trouve facile à utiliser.

Answer 2

Vous devriez attendre (mais pas longtemps!) Pour un nouveau test défaillant. Au moment où vous avez transformé votre test en faux, vous avez exactement les connaissances dont vous avez besoin: vous savez ce que vous essayez de développer, vous savez que vous avez une petite couverture de test unitaire, et vous savez qu'il est facile de simuler ce test. Et vous savez que vous l'avez truqué.

C'est donc le moment de découvrir un autre test que le faux courant ne réussira pas. Ramenez votre barre au rouge - et maintenant vous avez une autre décision à prendre: fake-le plus ou fais-le bien? Si c'est plus facile de garder le faux, fausse-le un peu plus et recommence. Mais si c'est plus facile, enfin, d'écrire le code dont vous avez besoin: écrivez-le. Vous l'écrivez en toute sécurité, avec juste assez de couverture de test pour vous sentir bien à ce sujet. Parfait!