J'ai du mal à trouver quand arrêter d'écrire des cas de test en utilisant TDD.
Disons qu'il faut écrire une méthode qui n'accepte que certaines chaînes, elle ne peut accepter que les chaînes ['red', ' green ',' blue '] , il est obligatoire et ne peut pas être vide.
J'écris le premier test qui échoue, je le rends vert, et ainsi de suite jusqu'à ce que j'aie le cas de test:
it('should accept red input', () => { /*...*/ }
it('should accept green input', () => { /*...*/ }
it('should accept blue input', () => { /*...*/ }
it('should not accept null input', () => { /*...*/ }
it('should not accept empty input', () => { /*...*/ }
À ce stade, tout se passe, devrais-je l'appeler un jour et partir ou devrais-je aller ajouter un test s'il échoue pour Purple ? Est-il utile d'ajouter ce test?
Si c'est le cas, je peux toujours nommer 10 autres couleurs à tester, devrais-je les considérer toutes aussi?
Cet exemple est simple, mais il y a des cas avec des expressions régulières qui ont des combinaisons infinies que je sais qui pourraient être un problème et je ne peux pas ajouter tous les cas de test auxquels je peux penser pour des contraintes de temps. Ce sont les pires, car je ne sais pas quand arrêter d'écrire du code de test, et trouver quand ça suffit.
Je comprends que je ne peux pas obtenir de réponse concrète à ce sujet, mais j'aimerais entendre par expérience de ce qui fonctionne la plupart du temps.
3 Réponses :
Une excellente réponse est de poster ici: Existe-t-il des tests unitaires excessifs?
En bref, vous considérez la probabilité d'échec et comparez cela au coût de l'écriture d'un scénario de test automatisé.
Dans votre cas, vous pouvez tester une autre couleur pour voir si elle la rejette correctement. Mais tester pour toutes les circonstances est inutile et impossible.
Si vous commencez à recevoir des erreurs répétitives sur une certaine valeur, vous voudrez peut-être l'ajouter au test. Sinon, les vérifications des limites feront l'affaire (Vide ou Aucun, comportement correct, un échec)
En général, vous voulez tester des classes d'entrée au lieu d'entrées spécifiques, à moins que vous ne sachiez déjà qu'une entrée spécifique produira une situation spécifique que vous devez couvrir avec les tests.
Dans votre exemple, je le décomposerais en quatre tests:
Vous avez raison de dire qu'avec l'analyse, l'espace d'entrée est énorme et couvre plus de cas que vous ne pouvez en tester de manière réaliste. Dans ce cas, j'opterais pour certains cas courants (les entrées nulles / vides, les entrées clairement attendues et inattendues, etc.) et j'essaierais de penser à des scénarios spécifiques où une entrée pourrait être mal classée comme (non) attendue. Peut-être qu'il y a deux couleurs «rouge» et «rougeâtre» et vous voulez tester que la fonction couvre les deux ou l'un, mais pas l'autre. Les couleurs spécifiques ne sont pas importantes dans ce cas, juste que l'une contient l'autre.
À ce stade, tout se passe, devrais-je l'appeler un jour et partir ou devrais-je ajouter un test s'il échoue pour Purple? Est-il utile d'ajouter ce test? Si c'est le cas, je peux toujours nommer 10 autres couleurs à tester, dois-je les considérer toutes aussi?
Une approche pour améliorer votre évaluation de votre sujet de test sans énumérer le monde entier est le test basé sur la propriété. Scott Wlaschin a écrit une bonne introduction à la technique .
Kent Beck est connu pour attirer l'attention sur la duplication des données entre le test et l'implémentation, et JB Rainsberger a suggéré que, dans le cadre de votre travail de "suppression de la duplication", les données ont tendance à se déplacer vers le test. Alors qu'est-ce que cela signifie?
Dans votre cas, il semble que vous puissiez séparer le sujet du test en deux parties - une partie ressemble à une base de données (carte, table de recherche) de noms de couleurs, l'autre partie une logique qui fait quelque chose d'intéressant étant donné une base de données de noms de couleurs.
Pour la dernière partie, vous vous retrouvez avec des tests comme "étant donné une base de données de [rouge, vert, bleu], le sujet de test prend-il le chemin qui n'est pas une couleur lorsque l'entrée est violette; étant donné une base de données de [rouge, vert, bleu, violet], le sujet du test prend-il le chemin qui-est-une-couleur lorsque l'entrée est violette ".
Cela vous laisse avec la base de données à vous soucier. Ce à quoi vous devez faire attention, c'est que le simple fait de tester que vous avez tapé les mêmes données à deux endroits différents n'est pas particulièrement utile.
Vous pourriez également considérer cette observation de Beck < / p>
Je suis payé pour du code qui fonctionne, pas pour des tests, donc ma philosophie est de tester le moins possible pour atteindre un niveau de confiance donné
N'oubliez pas que le temps investi dans les tests est du temps non investi ailleurs. Parfois, le bon jeu consiste à expédier, puis à revenir au code plus tard lorsque vous aurez appris quelque chose de nouveau sur son fonctionnement.