Je sais que TDD aide beaucoup et j'aime cette méthode de développement lorsque vous créez un test d'abord, puis mettez en œuvre la fonctionnalité. C'est très clair et correct.
Mais en raison de la saveur de mes projets, il arrive souvent que lorsque je commence à développer un module, je sais très peu de ce que je veux et de la façon dont il va regarder la fin. Les exigences apparaissent que je développe, il peut y avoir 2 ou 3 itérations lorsque je supprime tout ou partie de l'ancien code et écrivez nouveau.
Je vois deux problèmes: 1. Je veux voir le résultat dès que possible à comprendre que mes idées sont correctement ou mal. Les tests unitaires ralentissent ce processus. Il arrive donc souvent que je rédige des tests d'unité après la fin du code, ce que l'on sait être un mauvais modèle. 2. Si j'écris d'abord les tests, j'ai besoin de réécrire non seulement le code deux fois ou plus, mais aussi les tests. Il faut beaucoup de temps.
Quelqu'un pourrait-il me dire comment peut-on appliquer TDD dans une telle situation?
Merci d'avance!
11 Réponses :
Je veux voir le résultat dès que possible à comprendre que mes idées sont correctes ou mal. Les tests unitaires ralentissent ce processus.
Je ne suis pas d'accord. Les tests d'unités et TDD peuvent souvent accélérer obtenir des résultats car ils vous obligent à vous concentrer sur les résultats plutôt que de mettre en œuvre des tonnes de code que vous pourriez avoir besoin. Il vous permet également d'exécuter les différentes parties de votre code lorsque vous les écrivez afin que vous puissiez constamment voir quels résultats vous obtenez, plutôt que de devoir attendre que votre programme complet soit terminé.
TDD vous aide à exprimer l'intention de votre code. Cela signifie que l'écriture du test, vous devez dire ce que vous attendez de votre code. Comment vos attentes sont remplies est alors secondaire (c'est la mise en œuvre). Demandez-vous la question: "Qu'est-ce qui est plus important, la mise en œuvre ou la fonctionnalité fournie est?" S'il s'agit de la mise en œuvre, vous n'avez pas besoin d'écrire les tests. S'il s'agit de la fonctionnalité fournie, écrivez d'abord les tests d'abord vous aidera à cela.
Une autre chose précieuse est que, par TDD, vous n'ayez pas implémenter des fonctionnalités qui ne seront pas nécessaires. Vous n'abonnaissez que du code qui doit satisfaire l'intention. C'est aussi appelé Yagni (vous n'aurez pas besoin de cela).
Je trouve que TDD fonctionne particulièrement bien dans ce type de situation; En fait, je dirais que cela n'ait pas clairement clair et / ou que des exigences changeantes sont réellement très courantes.
Je trouve que les meilleures utilisations de TDD veillent à ce que votre code fait ce que vous attendez. Lorsque vous écrivez un code, vous devez savoir ce que vous voulez que ce soit, si les exigences sont claires ou non. La force de TDD ici est que, s'il existe une modification des exigences, vous pouvez simplement modifier un ou plusieurs de vos tests de l'unité pour refléter les exigences modifiées, puis mettre à jour votre code tout en étant sûr que vous ne brisez pas d'autres (inchangés ) Fonctionnalité.
Je pense qu'une chose qui trébuche beaucoup de personnes atteintes de TDD est l'hypothèse que Tous les tests doivent être écrits à l'avance. Je pense qu'il est plus efficace d'utiliser la règle de base que vous n'écrivez jamais de code de mise en œuvre pendant que tous vos tests passent; Cela garantit simplement que tout code est couvert, tout en veillant à ce que vous vérifiez que tout code fait ce que vous voulez que vous fassiez sans vous soucier de rédiger tous vos tests à l'avance.
Dans ce début de prototype-phase, je trouve que cela suffit à rédiger un code testable. C'est-à-dire que lorsque vous écrivez votre code, réfléchissez à la façon de rendre la possibilité de tester, mais pour l'instant, concentrez-vous sur le code lui-même et non les tests.
Vous devriez avoir les tests en place lorsque vous vous engagez.
TDD est une pratique qui vous permet de soigner les exigences. En se concentrant sur les tests, vous développez du code vérificateur qui implémente les fonctionnalités dont vous avez besoin.
Voici un article de blog que j'ai trouvé puissant dans l'explication de l'utilisation de TDD sur une échelle de processus de conception très itérative: http://blog.extracheese.org/2009/11/how_i_started_tdd.html .
Utiliser TDD pourrait réellement vous faire écrire du code plus rapide - ne pas pouvoir écrire un test pour un scénario spécifique pourrait signifier qu'il existe un problème dans les exigences.
Lorsque vous devez trouver ces endroits problématiques plus rapidement au lieu d'écrire 80% de votre code.
Il y a quelques éléments que vous pouvez faire pour rendre vos tests plus résistants au changement:
vous devriez essayer de réutiliser le code à l'intérieur vos tests sous une forme d'usine Méthodes qui crée votre test Objets avec les méthodes de vérification qui vérifie le résultat du test. Cette manière si un changement de comportement majeur se produit dans votre code que vous avez moins code à modifier dans votre test.
Utilisez un conteneur IOO au lieu de passer Arguments à vos principales classes - Encore une fois si la méthode signature changements que vous n'avez pas besoin de changer Tous vos tests.
Effectuez vos tests d'unité courts et isolés - chaque test doit vérifier un seul aspect de votre code et utiliser un cadre de moqueur / isolation pour effectuer le test indépendant des objets externes.
Code test et écrivez uniquement pour la fonctionnalité requise (Yagni). Essayez de vous demander quelle valeur que mon client recevra du code que j'écris. Ne créez pas une architecture surchargée, créez plutôt la pièce de fonctionnalité nécessaire par pièce tout en refactant votre code au fur et à mesure.
Il n'y a pas de telle sorte de le faire - si vous mesurez la durée de la durée de la durée, de la durée exacte de la durée pendant laquelle cela vous amène à écrire des cours, etc., alors cela prendra plus de temps avec TDD. Si vous êtes expérimenté, cela ajoutera environ 15%, si vous êtes nouveau, cela prendra au moins 60% de plus, sinon plus.
Mais, dans l'ensemble, vous serez plus rapide. Pourquoi?
ajoutez tout cela en haut et si vous mesurez à partir de la création à la livraison et que TDD est beaucoup, beaucoup plus vite - vous obtenez moins de défauts, vous prenez moins de risques, vous progressez à une vitesse constante (qui facilite l'assurance) et la liste. continue.
TDD vous rendra plus rapide, pas de question, mais ce n'est pas facile et vous devriez vous permettre de vous permettre d'apprendre et de ne pas être découragé si autrement, il semble plus lent.
Enfin, vous devriez examiner certaines techniques de BDD pour améliorer ce que vous faites avec TDD. Commencez par la fonctionnalité que vous souhaitez implémenter et descendre dans le code à partir de là en tirant des histoires, puis des scénarios. Concentrez-vous sur la mise en œuvre de votre scénario de solution par scénario en tranches verticales minces. Faire cela aidera à clarifier les exigences.
IMHO, votre problème principal est lorsque vous devez supprimer du code. Ceci est déchets et c'est ce qui doit être traité en premier.
Peut-être que vous puissiez prototyper ou utiliser des "solutions de pointe" pour valider les exigences et vos idées, puis appliquer TDD sur le code réel, une fois que les exigences sont stables.
Le risque est d'appliquer ceci et de devoir expédier le prototype.
Aussi, vous pouvez d'abord tester le "chemin sunny" d'abord et seulement implémenter le reste tel que la manipulation des erreurs ... Une fois les exigences qui ont été épinglées. Cependant, la deuxième phase de la mise en œuvre sera moins motivante.
Quel processus de développement utilisez-vous? Cela semble agile que vous rencontrez des itérations, mais pas dans un environnement qui le soutient pleinement.
+1 Pour mentionner des pointes - c'était ma première pensée aussi.
J'aime supprimer le code. Cela signifie que j'ai simplifié le code que je travaille.
Joshua Block a commenté quelque chose de similaire dans le livre "Coders au travail". Son conseil était d'écrire des exemples de la manière dont l'API serait utilisée (environ une page de longueur). Pensez ensuite aux exemples et à l'API beaucoup et à refacteur de l'API. Ensuite, écrivez la spécification et les tests de l'unité. Soyez préparé, cependant, pour refroidir l'API et réécrire la spécification lorsque vous implémentez l'API.
TDD va, pour presque quiconque, ralentir le développement initial. Donc, si la vitesse de développement initiale est de 10 sur une échelle de 1 à 10, avec TDD, vous pourriez vous déplacer autour d'un 8 si vous maîtrisez.
C'est le développement après ce point qui devient intéressant. À mesure que les projets grossissent, l'efficacité du développement diminue généralement - souvent à 3 sur la même échelle. Avec TDD, il est très possible de rester toujours dans la gamme 7-8.
Recherchez "la dette technique" pour une bonne lecture. En ce qui me concerne, tout code sans tests d'unité est une dette technique efficacement.
Lorsque je traite de conditions difficiles, je sais que mon code devra changer. Avoir des tests solides m'aident à me sentir plus à l'aise de changer mon code. Pratiquer TDD aide-moi à écrire des tests solides, et c'est pourquoi je le fais.
Bien que TDD soit principalement une technique de conception, elle bénéficie d'un grand avantage dans votre situation: elle encourage le programmeur à considérer les détails et les scénarios concrets. Lorsque je fais cela, je remarque que je trouve des lacunes ou des malentendus ou un manque de clarté dans les exigences assez rapidement. L'acte d'essayer d'écrire des tests me force à faire face au manque de clarté dans les exigences, plutôt que d'essayer de balayer ces difficultés sous le tapis.
Alors, lorsque j'ai des exigences difficiles, je pratique TDD, car cela vous aide à identifier les problèmes d'exigences spécifiques que je dois aborder, mais aussi parce qu'il m'encourage à écrire du code que je trouve plus facile à changer, si je comprends plus sur ce que J'ai besoin de construire.