En suivant la discussion dans les commentaires de Cette réponse < / a>, si un test TDD devrait toujours être effectué d'échec en premier?
6 Réponses :
TDD pour moi est plus d'un outil de conception, pas d'après-coup. Donc, il n'y a pas d'autre moyen, le test échouera simplement car il n'y a pas de code pour le faire passer encore, seulement après que je le crée que le test puisse jamais passer.
Bien sûr, il est précieux, car il s'agit donc d'une utile test de régression . À mon avis, les tests de régression sont plus importants que de tester le code nouvellement développé.
Dire qu'ils doivent toujours échouer d'abord, prennent une règle au-delà de la praticité.
Oui, les tests TDD doivent échouer avant qu'ils ne deviennent vert (travail). Sinon, vous ne savez pas si vous avez un test valide.
Je ne suis pas d'accord - prenez une langue statique où vous avez un test comme certains_value_should_always_be_false (). Écrire juste assez de code pour que la compilation de test va probablement effectuer le test de test, à moins que vous sabotez délibérément de saboter le test et définissez la valeur sous test sur TRUE.
Alors, comment adressez-vous des scénarios comme celui présenté dans l'OP?
@Jeremy frey - Vous avez raison de ne pas saboter vos tests pour faire échec du test initial. L'objectif n'est pas de la langue elle-même, mais de tester votre logique. Dans l'exemple que vous avez mentionné, le test semble trop trivial pour ajouter de la valeur si vous pouvez assumer la valeur pour toujours être fausse. J'espère que ça aide.
Je pense que le point de "échouer en premier" est d'éviter de vous moquer d'un test fonctionnant. Si vous avez un ensemble de tests vérifiant la même méthode avec différents paramètres, un (ou plusieurs) d'entre eux est susceptible de passer du début. Considérons cet exemple:
public void testDoFoo_matches() {
assertEquals("Geoff Hurst", createBar().doFoo(1966));
}
public void testDoFoo_validNoMatch() {
assertEquals("no match", createBar().doFoo(1));
}
public void testDoFoo_outOfRange() {
assertEquals(null, createBar().doFoo(-1));
}
public void testDoFoo_tryAgain() {
assertEquals("try again", createBar().doFoo(0));
}
@John quel changement avez-vous fait? l'avant et après avoir l'air pareil pour moi
@Rich: Il a ajouté des parenthèses. Vous pouvez cliquer sur le lien à côté de "édité" montrant combien de temps il a été édité (juste au-dessus de son nom) et vous pouvez voir toutes les différences et la note de modification.
@Ahmad, c'est ce que j'ai fait, autant que je puisse dire au texte avec le strikethrough et le nouveau texte sont les mêmes (copiés et collés le premier changement ci-dessous sans formatage) Createbar (). Dofoo (1966) CreateBar (). Dofoo (1966). Qu'est-ce que j'ai manqué
vous avez manqué la traînée ')' sur toutes les lignes de test
Ah merci, l'étendue de la surbrillance indiquait un changement plus important
IMHO, l'importance de l'échec d'abord est de s'assurer que le test que vous avez créé n'a pas de défaut. Vous pourriez, par exemple, oublier l'affirmation dans votre test et vous ne le sauriez jamais.
Un cas similaire se produit lorsque vous faites des tests de limites, vous avez déjà construit le code qui le couvre, mais il est recommandé de tester cela.
Je pense que ce n'est pas un gros problème pour votre test de ne pas échouer, mais vous devez vous assurer qu'il teste effectivement ce qu'il devrait (déboguer, peut-être).
Ce que vous demandez réellement, c'est comment vous pouvez tester le test pour vérifier qu'il est valide et il teste ce que vous avez l'intention.
Faire échec au début est une option OK, mais note que même si elle échoue lorsque vous planifiez d'échouer et de réussir après avoir refactorisé le code pour réussir, que reste ne fait pas signifie que votre test a réellement testé ce que vous vouliez ... bien sûr, vous pouvez écrire d'autres classes qui se comportent différemment pour tester votre test ... mais c'est en fait un test qui teste votre test original - Comment savez-vous que les Nouveau test est valide? : -)
Ainsi, faire un test d'échec d'abord est une bonne idée, mais il n'est toujours pas infaillible.
Je suis certes, au mieux, une recrue de langue dynamique (d'où le commentaire au lieu de réponse), mais mon sentiment d'intestin est - oui pour les langages dynamiques, et cela dépend des langues statiques. Le code qui échouerait la compilation dans une langue statique va courir dans une langue dynamique, mais faire échouer le test. Pour qu'une langue statique soit exécutée, vous devez ajouter une sorte de comportement de base au code à tester (même s'il s'agit de méthodes vides), ce qui pourrait entraîner une réussite d'un test correctement écrit.