Je construis une nouvelle application et j'essaie de respecter le développement "Test - Premier" que je peux fidèlement que possible. Je me trouve dans des situations où je dois mettre en œuvre / modifier une fonctionnalité qui a un effet d'invalidation d'un certain nombre de tests d'unités existants. Comment devrais-je m'occuper de cela? Comme je le vois, il y a 3 options:
mise à jour ou supprimer tous les tests existants pour répondre aux nouvelles exigences de fonctionnalité (en ajoutant plus besoin si nécessaire), puis implémentez la fonctionnalité
Implémentez d'abord la fonctionnalité, exécutez les tests pour voir les échecs et mettre à jour ou supprimer tout test échoué (en ajoutant plus besoin si nécessaire)
Ajouter de nouveaux tests pour la nouvelle fonctionnalité,
Implémentez la fonctionnalité, exécutez tous les tests
voir les anciens échouer, enlever ou
mettre à jour les anciens tests si nécessaire
La première option adhère à TDD, mais peut être contre-productive de manière excessive. La deuxième option est la plus facile, mais vous ne testez pas fidèlement fidèlement et que vous ne seriez pas correctement "couvert". La troisième option est un compromis des deux et attrayant à un degré, mais vous risquez de réécrire un test lorsque vous auriez pu juste mettre à jour une ancienne.
Je n'ai pas l'impression d'avoir une stratégie claire ici. Que faites-vous dans ces situations?
6 Réponses :
Je choisirais un test et je le modifierais pour nécessiter la nouvelle fonctionnalité. S'il n'y a pas de candidats évidents, c'est vraiment nouveau, je en créerais un. J'écrirais alors le code pour réussir ce test. À ce stade, je dirais mes autres tests et je remarquerais que certains d'entre eux échouent. À ce stade, je reviendrais à ce moment-là que chaque test soit corrigeant le test pour refléter la nouvelle fonctionnalité (il ne passerait donc aucun autre changement de code) ni mettre à jour le test en ce qui concerne la nouvelle fonctionnalité (ce qui peut nécessiter des modifications supplémentaires à la code sous test).
Je créerais de nouveaux tests pour la nouvelle fonctionnalité et mettez à jour les tests existants pour répondre à votre fonctionnalité. Si vous cassez un test déjà de travail, vous devez le réparer.
Est-ce une bonne pratique de mettre en œuvre une fonctionnalité de manière à ce que les nouvelles fonctionnalités nécessitent des tests d'unités existants à mettre à jour? Ou est-ce acceptable?
Mise en œuvre de la fonctionnalité comprend écrire / mettre à jour les tests de l'unité; C'est fondamental pour le développement axé sur les tests. Donc, vos deuxièmes deux options sont également TDD, pas seulement votre première. En pratique, je soupçonne que vous voudrez votre troisième option avec certains mods:
Débarrassez-vous des anciens tests et écrivez de nouveaux. Vous pourrez peut-être emprunter un code dans les anciens tests de quelques endroits, mais vous êtes mieux avec des tests philosophiquement en ligne avec ce que vous essayez de faire que de tenter de changer la nature de l'ancien test.
Les tests sont là pour soutenir ce que vous essayez d'accomplir et ne devriez pas travailler contre vous.
Je pense qu'il y a deux choses à considérer ici. Et je ne sais pas si vous ne pensez qu'à un seul ou à la fois.
La première partie est que vous avez modifié une fonctionnalité depuis les modifications de la spécification (ou du comportement attendu). Dans ce cas, je pense que la bonne chose à faire est de supprimer tous les tests décrivant les comportements qui ne sont plus valides. Depuis que je suis paresseux, je les commenterais ou les sauterais pour le moment. Ensuite, je commencerai à écrire de nouveaux tests (ou décroître / modifier les anciens) pour commencer à décrire le nouveau comportement jusqu'à la fin.
La deuxième partie doit faire si votre nouvelle fonctionnalité modifie une interface utilisée par d'autres composants et que leurs tests commencent à défaillir simplement parce que vous avez modifié la fonctionnalité. Dans ce cas, je voudrais simplement réparer les tests après une fois la fonctionnalité terminée.
Je pense que toutes les approches sont raisonnables. Vous arriverez au même résultat.
Certaines personnes aiment les petites étapes et pour travailler davantage dans l'intention originale de TDD: écrivez une ligne de test, écrivez une ligne de code pour le réparer, répéter. Si vous êtes vous, travaillez d'abord sur vos anciens tests, évoluant, évoluant - ou en retirant-- eux vers le nouveau système.
Si cela ne vous dérange pas de mordre un gros morceau, plongez dans un nouveau produit. Je trouve que cela est plus naturel, surtout lorsque la programmation paire lorsque vous pouvez être un peu plus audacieux.
peut vraiment dépendre de votre confort et de votre niveau de confiance.
J'aurais deuxième que la notion selon laquelle il est idéalement un changement ne doit casser un seul test. Vous pouvez donc souhaiter refroidir le code de test afin que ce soit le comportement que vous avez. Une sorte de méthode de configuration partagée peut être la solution.
C'est ce que je fais quand je pense à tout le code que j'ai testé qui a finalement été allé dans la poubelle: youtube.com/watch?v=tgbi3-q5com
Il semble étrange que faire un changement (correctement) pourrait casser plusieurs tests unitaires. Un ou deux peut-être, mais plusieurs? Est-il possible que votre unité teste trop trop?
@Beta, disons que vous ajoutez une exigence selon laquelle la mise en œuvre nécessite désormais une classe dépendante supplémentaire. Maintenant, vos autres tests ne fournissent pas de maxe de mise en œuvre de l'objet dépendant, alors lorsqu'ils vous dirigent d'obtenir un tas d'exceptions de référence NULL. Vous devez alors revenir en arrière et réparer votre code d'installation afin qu'ils passent ensuite.
@tvanfosson, en vérité, je parlais non seulement d'un test cassé, mais "non valides" qui ne décrivent plus avec précision une fonctionnalité, de sorte que vous et bêta à la fois des points.
@Beta, j'essaie de ne tester qu'une seule chose à la fois et, en tant que tels, plusieurs (petits) tests pourraient être utilisés pour une caractéristique donnée. Je ne pense pas que ce soit une question de chevauchement, mais j'obtiens ce que vous dites - cela pourrait être partiellement introduit par moi-même.
Post Exemples de vos tests et de vos tests sous test