J'essaie d'm'en tenir à l'approche TDD. J'ai donc fait des tests et ils échouent tous. Maintenant, je suis en train de mettre en œuvre. Mais maintenant que je suis en train de mettre en œuvre, j'ai vu que les méthodes sont trop simples pour échouer. En particulier, j'ai mis en œuvre le modèle d'observateur et tout ce qui se passe est que j'avais notifié à tous les observateurs enregistrés. Alors utilisez A pour chaque boucle et appelez notifiez. Cela semble certainement trop simple à casser. Maintenant que j'ai les tests dans des endroits devrais-je les supprimer? Cela semble également être un peu une perte de temps. Devrais-je essayer d'anticiper des méthodes qui seraient trop simples pour casser?
6 Réponses :
Non.
Les méthodes peuvent être trop simples pour se casser maintenant, mais cela ne signifie pas qu'ils n'auront jamais besoin d'être modifiés (et éventuellement cassé) à l'avenir.
Merci pour le commentaire. Alors devrais-je plutôt les laisser pour le moment et les ajouter plus tard si la méthode change. DANGER évident est que vous oubliez de mettre à jour le test de l'unité. Mais même lors de la modification, nous devrions d'abord avoir à écrire un test unitaire pour le changement afin que nous puissions l'attraper.
Laissez le test simple là-bas, si la méthode doit être modifiée et que c'est un changement de rupture, vous devrez alors modifier les tests de l'unité. Cependant, si ce n'est pas un changement de rupture et que les tests cessent de fonctionner, il y a un bogue dans votre changement.
Vous dites que c'est trop simple pour échouer:
for (i = 0; i < observers.length; ++j) {
// Notify observer observers[i]
}
Non A pour chaque énoncé. Le fait que chaque relevé est une construction de langue, il est donc essentiellement de réutiliser le compilateur. Si c'était une boucle normale avec Int i = 0, etc. alors je le ferais.
@uridium: C'est bien (vous n'avez pas indiqué quelle langue ou construire vous utilisiez, alors je suis allé avec un dénominateur commun). Le point est toujours debout; Pratiquement rien n'est trop simple pour vous tromper en quelque sorte, et les fonctions ont tendance à se développer dans la complexité au fil du temps.
@ T.J. Je suis d'accord, il ne peut y avoir aucun test de test de points pour acheter, mais vous testez également le bloc d'itérateur, qui doit affirmer que cela ne sera pas chiable pour être un itérateur personnalisé, il devrait bien sûr avoir ses propres tests, mais qui doit dire cela ne trouvera pas quelque chose que ces tests ont manqué.
Semblable à ce qu'est-ce que l'inquiétude binaire a déclaré, cela peut avoir l'impression de ré-tester pour chaque aujourd'hui, mais demain une exigence peut provoquer une présentation du programmeur de maintenance pour modifier la mise en œuvre vers une boucle ou tout ce que Le test donne confiance à la modification de la mise en œuvre n'a pas abouti à un changement de comportement. Bien sûr, le programmeur de maintenance pourrait aller: «Maintenant, il est plus compliqué, je vais écrire un test» - mais cela ne lui dit pas quels aspects du comportement actuel qu'il doit tester pour . Avoir déjà le test en place.
Supposons, par exemple, que l'un de vos observateurs a répondu à sa notification en supprimant un autre observateur. Ce test générerait alors une erreur - et c'est une erreur qui serait difficile de déboguer sans ce test. Rien n'est trop simple pour casser.
@Carlmanaster dans le cas de test pour cette méthode, vous ajouteriez quelques observateurs de test qui ne font rien, ce ne sera donc pas les observateurs réels qui agissent dans l'application en cours d'exécution (sinon, vous n'êtes pas des tests unitaires). Donc, le test ne l'attraperait pas.
oui; Si vous testez la fonctionnalité de la machine compilation / virtuelle sous-jacente, votre test est trop simple. À moins que, c'est-à-dire que vous ne faites pas confiance à cette pièce particulière de la machine compilation / virtuelle qui est exercée.
Mais, bien sûr, la réalité des tests est un peu plus complexe qu'une réponse oui / non à cette question. Comme indiqué dans une autre réponse, si vous avez déjà écrit les tests, ne les supprimez pas. Mais vous ne devez pas non plus les utiliser dans un contexte de couverture de code comme argument de confiance.
Non.
Vous le faites exactement bien: Ecrire des tests qui échouent d'abord, puis les fixant. Laissez ces tests seuls, écrivez plus complexes à l'avenir si vous pensez que vous en aurez besoin (par exemple, reproduire des bugs).
Plus vous avez des tests, moins vous allez avoir mal à l'avenir. Nevermind leur simplicité.
Maintenant que vous avez obtenu tous ces tests à réussir, laissez-les seuls. S'ils fonctionnent assez rapidement, ils ne seraient pas un fardeau pour quiconque.
Cependant, à l'avenir, vous voudrez peut-être écrire juste un test de défaut à la fois. (Voir Les trois règles ). En effet, cela permettra à votre conception de s'améliorer pendant que vous développez votre code.
Lorsque tous vos tests ont omis et aucune implémentation, vous aviez corrigé votre conception et que ce qui fonctionne maintenant, vous pouvez être détesté de refroidir la conception pour l'améliorer.
Je soupçonne également que vous ayez eu un moment difficile à mettre en œuvre votre code, chaque étape de mise en œuvre aurait pu briser plus de tests qu'il n'y a pas passé, mais hé, je devine seulement!