J'ai un projet que je construit que je dois changer une méthode pour se comporter légèrement différente. J'ai plusieurs tests unitaires déjà construits contre cette méthode, mais je devrai ajouter davantage pour couvrir le nouveau comportement que je vais y ajouter. Est-il bon de modifier / ajouter ces tests avant de passer le code de code ou modifiez-vous votre code, corrigez-vous les tests brisés et ajoutez les nouveaux tests pour couvrir le nouveau comportement?
6 Réponses :
Il est préférable de mettre à jour les tests en premier et de les laisser échouer, puis revenir en arrière et mettre à jour le code jusqu'à ce que le test passe. A.k.a le développement axé sur le test ou le premier développement de test.
Si vous devez suivre TDD pratiques, vous devez d'abord mettre à jour vos tests. Vous aurez des cas de test brisés qui devront être corrigés lorsque vous réparez votre code.
Le mot a été choisi avec intention :)
Ce que je fais est le code Tout d'abord, puis créez des tests après. Depuis que vous pourriez avoir un cas où vous programmez votre test pour travailler d'une manière ou d'une autre, lorsque vous vous déconnecterez, vous ne pouvez pas le faire. Donc, vous devrez modifier à nouveau les tests.
De mon expérience, cela conduit aux tests étant biaisés vers le code écrit, plutôt que les exigences. Écrire les tests Premièrement est le meilleur moyen d'obtenir des tests appropriés et des tests appropriés sont très utiles pour obtenir le code correct.
Ils peuvent être oui. C'est donc quelque chose que je cherche. Ce que je teste, c'est tous les chemins de code.
Ecrire des tests après que le code porte l'hypothèse implicite selon laquelle le code est correct. Si c'est votre hypothèse, la rédaction du test est une perte de temps. Dans des cas triviaux, cela peut même être une hypothèse sûre, mais a) je suppose que vous avez affaire à beaucoup de cas non triviaux dans votre travail quotidien, et b) si le code est que des tests d'écriture triviaux sont probablement pas un usage sage de votre temps. Les tests d'écriture d'abord définissent comportement correct, plutôt que sur l'estampage de caoutchouc un "col" après le fait.
Si vous testez le premier développement, vous devez au minimum un nouveau test qui justifie le changement. Le changement pourrait alors briser les anciens tests et vous pourriez les réparer après que vous les voyiez échouer, si le changement est accessoire au test. Si, toutefois, vous savez que le test utilisé pour tester l'ancien comportement et qu'il doit simplement changer pour le nouveau comportement, il n'ya aucune raison de ne pas simplement modifier ce test au lieu d'écrire un nouveau.
Cela ne vaut pas l'effort (à mon avis) pour déterminer quels tests vont casser avec le changement et les changer d'abord parce que le coureur de test vous indiquera qu'après votre changement.
Edit (en réponse à Commentaire): Je préfère écrire le test en premier, mais c'est le style TDD. Dans ce cas, la conception des entraînements de test. Il y a aussi un rythme et un modèle à ce type de développement (refacteur rouge-vert). L'inverse de l'autre solution est plus la solution de l'unité pure, vous avez déjà conçu et mis en œuvre ce que vous voulez, vous le testez maintenant. Il n'y a rien de mal à cela, c'est une approche de développement différente et le choix ne dépend pas de l'existence d'autres tests. C'est vraiment une approche de développement en général.
Je suis mon cas particulier, les anciens tests devraient tous toujours fonctionner comme ils sont écrits. J'ajoute simplement un ensemble supplémentaire de fonctionnalités à une méthode particulière qui n'est déclenchée par aucun test existant, je dois donc écrire de nouveaux tests pour couvrir cela. Souhaitez-vous d'abord écrire ces tests ou faire le changement, puis coder les nouveaux tests? Je prends pour acquis que tous les anciens tests devraient tous toujours travailler.
La bonne nouvelle est que vous n'avez pas à le prendre pour acquis - vous pouvez exécuter les tests. Parce que je trouve le processus TDD utile dans mon propre travail, je suggérerais d'écrire les tests d'abord - définir quantitativement ce que vous voulez que le code fasse avant de mettre en œuvre. Voir ma réponse pour plus de détails.
Je préfère personnellement écrire la fonctionnalité d'abord, puis effectuer les tests d'unité (le cas échéant sur la fonctionnalité spécifique). Si c'est quelque chose qui ne vaut vraiment pas la peine de tester unitaire, je le saute habituellement. J'ai constaté que, c'est généralement une perte de temps pour ajouter un test d'unité au code Il est facile de repérer la productivité gaspillée lorsque vous refacteur quelque chose et que vous réalisez que vous avez cassé la moitié des tests de l'unité qui n'ajoutent pas de valeur pour commencer; puisque une faute aurait été facilement tachetée en premier lieu. Donc, tout cet effort est une perte de temps.
Si vous travaillez dans un environnement où il n'y a pas d'incitation à livrer rapidement et à vous adapter rapidement, je suppose que des tonnes de tests unitaires sont réalisables. Sinon, vous venez d'augmenter vos coûts par tout un tas sans ajouter de plus en plus de valeur à vos utilisateurs. tout que vous écrivez. Il y a certainement lieu où il est très utile de l'avoir, mais cela ne s'étend guère à tout votre code.
Si vous cassez la moitié de vos tests, vous ne refactez pas; Vous faites des changements fonctionnels. Le refactoring ne modifie pas le comportement observable du logiciel.
Je vais admettre que je triche parfois. Si un changement est assez simple pour que je puisse connaître le résultat avec certitude, je changerai parfois de code, puis teste. Comme si je multiplie un chiffre par une constante et que tout ce que je fais, c'est changer la constante, je vais aller de l'avant avec le changement et mettre à jour le cas de test après.
Si vous faites quelque chose, même légèrement plus complexe, je vous conseillerais de m'en tenir à l'orthodoxie TDD et de changer le test en premier. Définissez ce que vous voulez faire avant de le faire. En outre, je vous recommanderais de mettre de nouveaux tests après les tests préexistants , de sorte que les tests liés aux fonctionnalités existantes que vous souhaitez préserver sont exécutés d'abord, vous assurant que vous n'avez rien brisé (ou que vous n'avez pas annulé rien (ni vous alerter Dès que possible que vous avez).