Le développement axé sur le test (TDD) a-t-il bénéficié d'un projet réel mondial?
Je ne suis pas nouveau pour coder. J'ai codé (sérieusement) depuis plus de 15 ans maintenant. J'ai toujours eu des tests pour mon code. Cependant, au cours des derniers mois, j'apprends conception/développement tordus à tester (TDD) en utilisant Ruby sur rails . Jusqu'à présent, je ne vois pas l'avantage.
Je vois des avantages pour écrire des tests pour certaines choses, mais très peu. Et bien que j'aime bien l'idée d'écrire le test d'abord, je trouve que je passe beaucoup plus de temps à essayer de déboguer mes tests pour les amener à dire ce que je veux vraiment dire que je débogage du code réel. C'est probablement parce que le code de test est souvent sensiblement plus compliqué que le code qu'il teste. J'espère que c'est juste l'inexpérience avec les outils disponibles ( RSPec dans ce cas).
Je dois dire cependant, à ce stade, le niveau de frustration mêlé à un manque de performance décevant est au-delà inacceptable. Jusqu'à présent, la seule valeur que je constate de TDD est une bibliothèque croissante de fichiers RSPEC servant de modèles pour d'autres projets/fichiers. Ce qui n'est pas beaucoup plus utile, peut-être moins utile que les fichiers de code de projet réels.
En lisant la littérature disponible, je remarque que TDD semble être un temps massif de l'évier à l'avant, mais ne paient pas à la fin. Je me demandais simplement, y a-t-il des exemples de monde réels? Cette frustration massive est-elle jamais rentable dans le monde réel?
J'espère vraiment que je n'ai pas manqué cette question quelque part ailleurs ici. J'ai cherché, mais toutes les questions/réponses sont de plusieurs années à ce stade. C'était une occasion rare lorsque j'ai trouvé un développeur qui dirait tout de mal à propos de TDD, c'est pourquoi j'ai passé autant de temps à ce sujet que moi. Cependant, j'ai remarqué que personne ne semble indiquer des exemples spécifiques du monde réel. J'ai lu une réponse qui a déclaré que le gars de débogage du code en 2011 vous remercierait d'avoir une suite de tests d'unité complète (je pense que ce commentaire a été fait en 2008).
Alors, je me demandais simplement, après toutes ces années, avons-nous enfin des exemples montrant que le gain est réel? Quelqu'un a-t-il réellement hérité ou revenu au code conçu/développé avec TDD et dispose d'un ensemble complet de tests unitaires et a réellement ressenti un gain? Ou avez-vous trouvé que vous dépensiez tellement de temps à essayer de déterminer ce que le test teste (et pourquoi il était important) que vous veniez de jeter tout le désordre et de creuser dans le code?
Ce document démontre que TDD ajoute 15 à 35% de temps de développement en échange d'une réduction de 40 à 90% de la densité de défauts sur des projets autrement semblables à ressembler à des projets.
L'article fait référence à un papier complet (PDF) - Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat et Laurie Williams. "Réaliser une amélioration de la qualité grâce au développement axé sur les tests: résultats et expériences de quatre équipes industrielles". ESE 2008.
Abstrait Développement axé sur les tests (TDD) est une pratique de développement logicielle utilisée sporadiquement pendant des décennies. Avec cette pratique, un cycles d'ingénieur logiciel Minute par -Minute entre les tests d'unité d'échec et l'écriture de code de mise en œuvre pour réussir ces tests. Le développement de Testdriven a récemment ré-émergé comme une pratique critique permettant une pratique capable de procéder à des méthodologies de développement logicielles. Cependant, peu de preuves empiriques soutient ou réfute l'utilité de cette pratique dans un contexte industriel. Des études de cas ont été menées avec trois équipes de développement chez Microsoft et l'une à IBM qui ont adopté TDD. Les résultats des études de cas indiquent que la densité de défaut de pré-libération des quatre produits a diminué entre 40% et 90% par rapport à des projets similaires qui n'ont pas utilisé la pratique de la TDD. Subjectivement, les équipes ont connu une augmentation de 15 à 35% du temps de développement initial après l'adoption de TDD.
Le document complet résume brièvement les études empiriques pertinentes sur TDD et leurs résultats de haut niveau (Section 3 Works associés), y compris George et Williams 2003, Müller et Hagner (2002), Erdogmus et al. (2005), Müller et Tichy (2001), Janzen et Seiedian (2006).
Je vois des avantages pour écrire des tests pour certaines choses, mais très peu. Et bien que j'aime bien l'idée d'écrire le test d'abord, je trouve que je passe beaucoup plus de temps à essayer de déboguer mes tests pour les amener à dire ce que je veux vraiment dire que je débogage du code réel.
Je travaille TDD depuis trois ans et mon expérience est exacte. Je passe moins de temps à écrire des tests unitaires que j'aurais débogué le code, n'avais-je pas écrit les tests de l'unité.
Non seulement je fais TDD, je travaille dehors-in, c'est-à-dire que j'ai d'abord implémenter la couche supérieure/interface graphique TDD. La mise en œuvre de la couche supérieure Définit les exigences relatives à la couche suivante dans le système, que je développe à l'aide de TDD, etc. jusqu'à ce que tout code requis pour la fonction ait été mis en œuvre. Souvent, j'effectue cela après avoir mis en œuvre une fonctionnalité comme celle-ci, et je fume, testez la fonctionnalité du système actuel, cela fonctionne la première fois. Pas tout le temps, mais souvent.
Et étant donné qu'il faut beaucoup plus de temps pour fumer, testez une fonctionnalité dans le système actuel que nécessaire pour exécuter quelques tests unitaires, je sauvegarde des quantités humusques de temps. Il est en fait plus rapide pour moi de mettre en œuvre une fonctionnalité utilisant TDD qu'il ne doit pas implémenter la fonctionnalité ne pas écrire des tests d'unité.
Mais les tests d'une unité d'écriture sont une compétence qui doit être apprise et maîtrisée, comme toute autre compétence de programmation. Quand j'ai commencé à faire de TDD, j'ai eu 12 ans d'expérience professionnelle avec la programmation et j'étais un programmeur très accompli. Je pensais que l'écriture de grandes suites de test pour le code système serait une chose simple. Mais comme la quantité de code de test a augmenté et que différentes parties du système ont été modifiées et que les tests existants devaient être modifiés, j'ai appris que la structuration et l'écriture test sont en soi une compétence qui doit être apprise et maîtrisée. Tous les codes ne sont pas également testables. Le code système doit être très lâchement couplé afin d'être efficacement testable. En fait, apprendre TDD m'a aidé à rendre le code système plus facilement couplé de manière lâche.
Mais mon efficacité actuelle de TDD de travail provient d'une combinaison de la maîtrise de la base de tests d'unité, mais également de maîtriser la technologie, le système est mis en œuvre dans ce cas (C # dans ce cas).
Faire TDD tout en apprenant une nouvelle technologie peut être difficile, par ex. Bien que je faisais un peu de programmation iPhone, je n'écris pas une quantité importante de tests unitaires, car je ne maîtrise pas la langue, l'objectif c, ni ne maîtrise la bibliothèque. Je n'ai donc aucune idée de la structure des tests d'unité, même moins de la structure du code système comment le rendre testable.
Mais dans quelle mesure fonctionne-t-il sur de vrais projets?
Sur le projet, je travaille depuis quelques années au cours des deux dernières années, bien que le Code soit suffisamment couvert par des tests unitaires, je suis le seul à écrire les tests. Mais la grande suite de tests me donne la confiance en pouvant refactuer le système et avoir la foi le système fonctionnera correctement si la suite de test passe.
Malheureusement, parce que de nombreux tests sont écrits après le code système, de nombreux tests eux-mêmes sont défectueux, c'est-à-dire qu'ils ne testent pas vraiment ce qu'ils étaient destinés à tester. Cet IMHO ne peut pas être évité. Chaque fois que vous écrivez un code de code, il existe une probabilité que le code ne fonctionne pas comme vous le vouliez, c'est-à-dire un bogue. Il en va de même pour le code de test. Par conséquent, il existe une probabilité que vous écrivez un test qui passe même si le code qu'il devrait être testé ne fonctionne pas comme prévu.
Écrire d'abord le test, vérifiant non seulement que vous obtenez une panne de test, mais que le test échoue avec exactement le message d'erreur que vous attendez avant de mettre en oeuvre le code système réduit sérieusement le risque d'un bogue dans le code de test de l'unité.
Donc, pour résumer, dans mon expérience une fois que vous avez maîtrisé l'art de TDD, vous n'allez pas simplement gagner du temps à long terme, vous gagnerez du temps à l'avant. Mais cela prend du temps, même pour un programmeur expérimenté, maîtriser l'art de TDD. Et cela prend encore plus longtemps pour une équipe de développeurs de compétences variées pour maîtriser l'art de TDD.
Nous avons bénéficié massivement.
Nous sommes un commerçant de niveau 1, ce qui signifie que nous traitons plus de six millions de transactions de paiement par an.
Notre système de passerelle de paiement comporte des milliers de tests d'unité et d'intégration. Ces tests nous donnent confiance en notre capacité à traiter les paiements. Vous voulez être sûr que votre voiture de voiture fonctionne, n'est-ce pas? Nous voulons être convaincus que nous ne perdons pas notre entreprise parce que nous ne pouvons pas traiter les paiements.
La couverture de code vous donne cette confiance. Bien sûr que cela ne suffit pas seul, mais c'est un très bon début.
La plupart de notre système de passerelle de paiement a été écrit à l'aide de TDD. Certains aspects étaient plutôt difficiles à tester, nous avons donc décidé de couper des coins en sacrifiant une couverture de code. Nous reviendrons et abordons ces problèmes.
Personnellement, j'ai du mal à écrire une logique avant d'écrire des tests. Cela dit, cela m'a pris un peu de temps pour commencer à penser à TDD Way.
VISA PCI Référence: http://usa.visa.com/merChants/risk_management/cisp_merChants.html
Bien que des tests puissent être souvent considérés comme une façon de faire trop de personnes par certaines personnes, je pense que cela vaut vraiment la peine de la peine dans certains cas.
J'ai développé un solutionneur de Sudoku tueur pour l'école pendant environ 3 mois, il utilise de nombreuses "stratégies" pour supprimer les possibilités et les solutions. Le fait est que, une erreur dans une possibilité peut être fatale et entraîner un problème pour résoudre le Sudoku car, lorsque certaines possibilités sont supprimées, vous n'essayez plus, et si c'était la solution, le programme ne peut pas résoudre la grille plus.
Mais il est très difficile de tester manuellement, je veux dire qu'il y a une grille, je peux voir quelles strattois font ce que fait dans un exemple réel, mais je ne peux tout simplement pas vérifier à chaque fois qu'une stratégie s'applique, car cela représente trop de données.
Et des stratégies appliquées sur une certaine grille sont assez "aléatoires", c'est-à-dire que vous ne devez pas utiliser tout sur une grille particulière.
J'ai donc écrit des tests sur chaque stratégie, en vérifiant le résultat sur chaque cellule, en utilisant simplement des situations simples (par exemple, deux cellules ont déjà supprimé des possibilités) et cela m'a sauvé des heures par jour lorsque je disposais malheureusement une grille qui ne pouvait pas être résolue. Parce que je savais déjà où était le problème.
L'avantage de TDD est que vous comprenez comment appelle votre code avant votre écriture du code réel.
En d'autres termes, TDD aide à concevoir votre API.
D'après mon expérience, cela se traduit par une meilleure API's à son tour donne un meilleur code.
EDIT: Comme je l'ai écrit, c'était "dans mon expérience", c'est-à-dire lorsque vous écrivez "Projets du monde réel", mais malheureusement, il s'agit d'une base de code source fermée, je ne peux pas laisser le monde voir. Je peux comprendre aux commentaires que c'est ce que c'est en réalité a demandé, et non seulement une confirmation de la simple existence de tels projets.
J'ai également trouvé - encore une fois dans mon expérience personnelle - que le véritable avantage montre lorsque vous entrez en mode de maintenance, car les exigences ont tendance à changer. L'API de nettoyeur a rendu beaucoup plus facile d'exprimer les exigences nouvelles ou modifiées dans le code de test, et tous les tests le rendent très facile à voir pour un futur mainteneur Comment le code doit être appelé et que peut-on attendre.
Les cas de test sont en coursives de la spécification et vous permettent de voir très facilement votre API. C'est peut-être la forme la plus utile de "Comment" - Documentation que j'ai vue jusqu'à présent (comparer à la "Pourquoi" - Documentation comme Javadoc) Comme vous êtes certain qu'il est correct (sinon, le test échouerait).
Dernièrement, j'ai dû maintenir un client FTP script avec un très grand ensemble d'options qui influencent toutes la façon dont l'application fonctionne. TDD a été introduit récemment pour une nouvelle fonctionnalité et la grande suite de tests nous permet de faire des correctifs tout en étant confiant que la fonctionnalité utilisée fonctionne toujours comme prévu. En d'autres termes, cette transition s'est révélée payer très rapidement.
Quelle est la valeur d'une approche particulière de test est dépend de la mission critique du système est en cours d'élaboration, et combien d'autres système critique dépend. Un script de livre d'or simple pour votre site Web pourrait difficilement être considéré comme une mission critique, mais si le site Web qu'il s'exécute pourrait potentiellement être compromis par un bogue permettant une entrée non filtrée à la base de données et que ce site offre un service vital, puis il devient soudainement beaucoup plus IMPORTANT POUR LE SCRIPT DE GOYBOOD D'être minutieusement testé. Il en va de même pour le Cadre/Code de la bibliothèque. Si vous développez un cadre avec un bogue, chaque application utilise cette fonctionnalité-cadre a également le même bug.
Le développement piloté par le test vous donne une couche supplémentaire de sécurité en matière de tests. Si vous écrivez les tests à côté ou même après que vous souhaitiez tester le code, il y a un risque réel que vous obtiendrez les tests. Si vous écrivez d'abord tous les tests, alors comment le code fonctionne en interne ne peut pas influencer ce que vous écrivez des tests pour, et il est donc moins possible d'écrire des tests par inadvertance qui pensent que une sortie erronée particulière est correcte.
Le développement axé sur le test encourage également vos développeurs à écrire du code facile à tester, car ils ne veulent pas se donner encore plus de travail à faire! Le code facile à tester a tendance à être code facile à comprendre, à réutiliser et à entretenir.
Et la maintenance est l'endroit où vous allez vraiment récolter les récompenses de TDD. La grande majorité des efforts de programmation dépensés sur des logiciels sont liés à la maintenance. Cela signifie apporter des modifications au code en direct pour lui donner de nouvelles fonctionnalités, résoudre des bugs ou l'adapter à de nouvelles situations. Lorsque vous apportez de tels changements, vous souhaitez être sûr que les modifications que vous effectuez ont l'effet souhaité, et plus important encore, ils n'ont pas d'effet inattendu sur les effets. Si vous avez une suite de test complet pour votre code, il est facile de vérifier que les modifications que vous apportez ne casse pas autre chose, et si les modifications que vous faites font une pause, vous pouvez rapidement localiser la raison pour laquelle. Les avantages sont à long terme.
Vous avez dit ce qui suit dans votre question:
Je vois des avantages pour écrire des tests pour certaines choses, mais très peu. Et bien que j'aime bien l'idée d'écrire le test d'abord, je trouve que je passe beaucoup plus de temps à essayer de déboguer mes tests pour les amener à dire ce que je veux vraiment dire que je débogage du code réel. C'est probablement parce que le code de test est souvent sensiblement plus compliqué que le code qu'il teste. J'espère que c'est juste l'inexpérience avec les outils disponibles (RSPEC dans ce cas).
Cela semble me suggérer que vous n'êtes pas tout à fait de tester. Un test unitaire est censé être extrêmement simple, juste une séquence d'appels de méthode, suivie d'une affirmation de comparer le résultat attendu contre le résultat réel. Ils sont censés être simples car les bugs de vos tests seraient désastreux et si vous introduisez des boucles, une branche ou une autre commande de programme au test dans le test, il devient plus probable que le test aura un bogue introduit. Si vous dépensez de nombreux tests de débogage de temps, cela indique que vos tests sont trop compliqués et vous devriez les simplifier.
Si les tests ne peuvent pas être simplifiés, que ce fait seul suggère qu'il y a quelque chose qui ne va pas avec le code sous test. Par exemple, si votre classe a de longues méthodes, des méthodes avec beaucoup d'instructions if/electrosif/sinon ou de commutation ou un grand nombre de méthodes contenant des interactions complexes dictées par l'état actuel de la classe, les tests doivent alors être extrêmement complexes. fournir une couverture de code complète et tester toutes les éventualités. Si votre classe a des dépendances codées dures sur d'autres classes, cela augmentera à nouveau le nombre de cerceaux que vous devrez sauter afin de tester efficacement votre code.
Si vous gardez vos cours petites et très concentrées, avec de courtes méthodes avec quelques chemins d'exécution et essayez d'éliminer l'état interne, les tests peuvent être simplifiés. Et c'est une sorte du coquelicot de la matière. Bon code est intrinsèquement facile à tester. Si le code n'est pas facile à tester, il y a probablement quelque chose qui ne va pas.
Les tests d'une unité d'écriture sont quelque chose qui vous avantagent à long terme et en les évitant simplement de stocker des problèmes pour plus tard. Vous ne connaissez peut-être pas le concept de dette technique, mais cela fonctionne beaucoup comme la dette financière. Ne pas écrire des tests, ne pas commenter le code, écrire dans des dépendances codées durement et donc les moyens d'entrer endetté. Vous "empruntez" le temps en coupant des coins plus tôt et cela pourrait vous aider à frapper une date limite serrée, mais le temps que vous économisez plus tôt dans le projet est en prêt. Chaque jour qui passe sans nettoyer le code, le commentaire correctement ou la construction d'une suite de test vous coûtera de votre intérêt. Plus il continue, plus l'intérêt s'accumule. Finalement, vous découvrirez que votre code est devenu un désordre enchevêtré que vous ne pouvez pas apporter des modifications sans déclencher des conséquences inattendues. Les intérêts sur le prêt temporel que vous avez sorti tôt dans le projet et n'ont pas réussi à rembourser plus tard sont revenus pour vous mordre et que vous êtes maintenant en faillite - le temps nécessaire pour résoudre les problèmes avec le système existant dépasse le temps qu'il faudrait pour réécrire de zéro.
Vous pouvez penser aux tests de l'unité d'écriture tôt et les maintenir à jour en tant que forme de "crédit technique". Vous mettez du temps à la banque en passant le plus tôt dans le projet sur la bonne pratique. Vous gagnerez des intérêts sur cette prévoyance plus tard lorsque vous arrivez à la phase de maintenance du projet. Lorsque vous souhaitez modifier une modification, vous pouvez facilement valider l'exactitude de la modification et qu'il n'a pas d'effets secondaires indésirables, et vous pouvez vous mettre à jour la porte rapidement et sans fausseté. Si les bugs se présentent, vous pouvez ajouter un nouveau test d'unité qui exerce le bogue, puis corrige le bogue dans le code. Lorsque vous exécutez ensuite le test de l'unité, vous pourrez vérifier que le bogue a été corrigé et qu'il n'a pas causé d'autres problèmes. De plus, vous éviterez des "régressions", où un bogue précédemment fixe est réintroduit car il n'y a rien de documenter pourquoi les choses ont été modifiées.
TL: DR - Oui, ils sont une aide réelle mondiale, mais ils sont un investissement. Les avantages ne deviennent apparents que plus tard.
J'utilise TDD assez souvent au travail. Mon expérience est que TDD se justifie parce que vous ne payez pas de temps ou d'effort supplémentaire, vous sauvegarder IT.
Depuis que j'utilise TDD, je passe beaucoup moins de temps de débogage ou tel. Cela fonctionne simplement dès le début car je ne considère pas le code productif tel que écrit tant que les tests ne passent pas.
QA rapporte beaucoup moins de bogues, nous économisons donc des coûts pour réparer notre code après une publication. En effet, TDD ne vous permet pas d'écrire du code sans test, de sorte que la couverture du code est bien meilleure.
Je peux courir mon code (productif) beaucoup plus souvent et plus rapide car je n'ai pas besoin de démarrer l'ensemble du serveur d'applications. Démarrer le test de l'unité est un ordre de grandeur plus rapide. Bien sûr, je n'en profite que lorsque le test est déjà exécutable lorsque je souhaite essayer le code productif. Lorsque les tests viennent ensuite, cette prestation est manquée.
Je fais beaucoup moins de tests manuels. Mes collègues qui ne pratiquent pas TDD dépensent beaucoup de temps en cliquant sur l'application jusqu'à ce qu'ils atteignent le point où le nouveau code est exécuté. Je ne teste que manuellement une fois, juste avant de m'engager vers la version de la version.
Même si j'utilise un débogueur, il est beaucoup plus rapide de déboguer l'exécution d'un test que de toute l'application.
Peut-être que vous pensez des tests d'unités comme des tests de régression. C'est l'une de leurs objectifs, mais les comprendre comme un outil pour Développement les rend beaucoup plus utiles.
Un autre avantage (en plus de ceux mentionnés par les autres personnes qui ont répondu) se lancent lorsque des testeurs d'acceptation des clients ou (Heaven nous interdisent) les utilisateurs de la production découvrent un bogue. Tournez le rapport de bogue en un test de style TDD pour la classe qui semble être en défaut. Regarder ça échoue. Répare le. Regarder ça passe. Ensuite, vous savez que vous avez corrigé le bogue. Cette technique m'a sauvé des heures.
Eh bien, je sais que je profite personnellement en étant deux fois plus vite que mes collègues développeurs et écrivez moins de la moitié des bugs qu'ils font parce qu'ils ne font pas TDD. Les gens qui devraient probablement être meilleurs que moi même ... Je les surprends-je d'au moins un facteur de 2.
Je ne suis pas arrivé là-bas tout de suite. Je suis plutôt bon à l'écriture de code de la brassard et sans harnais. Semblait être un gros gaspillage pour écrire toute cette merde supplémentaire. Mais cela fait plusieurs choses, y compris (non exclusive):
- Forcer une conception axée sur le découplage et la réutilisation (tout doit être réutilisé dans un test unitaire).
- Fournir une plate-forme pour développer un code dans de petits morceaux et modules, donc je n'ai pas besoin de tout comprendre et de terminer avant d'exécuter une simple "compilation de la compilation et de l'entrée" type de test.
- Fournir une plate-forme de test rapide pour apporter des modifications lorsque les personnes exigent des modifications de fonctionnalités que je n'attendais pas.
Un exemple sur ce bit ultérieur est un projet que je travaille actuellement sur l'endroit où la tête a soudainement décidé de réécrire totalement le protocole de communication qu'il utilisait à peu près 0. J'ai pu répondre à ce changement dans 2 heures, car j'avais déjà découplé cela de tout le reste et j'ai pu y travailler entièrement de manière totalement indépendante jusqu'à ce que le dernier lien soit ensemble et intégrez l'étape de test. La plupart de mes collègues auraient probablement été dedans pendant une journée ou plus parce que leur code ne serait pas découplé et qu'ils changeraient ici, là-bas, partout ... Compiler tout ... Test d'intégration ... Répéter, Répétition ... prend beaucoup plus longtemps de cette façon et n'est nulle part près aussi stable.
La réponse est oui. Dans ma société, nous développons une demande C++ depuis plus de 20 ans. L'année dernière, nous sommes entrés dans TDD dans de nouveaux modules et les taux de défaut ont considérablement diminué. Nous avons tellement aimé que certains d'entre nous ajoutent même des tests au code hérité à chaque fois que nous changeons quelque chose là-bas.
De plus, tout un module a été achevé du début à la fin de la production, sans jamais démontrer un bogue (et c'est un module critique, aussi). Son développement était ainsi plus rapide que d'habitude, car généralement ce qui se produirait autrement, c'est qu'un module serait "complété", seulement pour retourner 4-5 fois de tests bêta pour les corrections de bugs. Ce fut une amélioration substantielle et les développeurs étaient également satisfaits du nouveau processus.
Je n'ai pas fait beaucoup de Rails TDD, mais j'ai déjà fait beaucoup en C++, c #, Java et python. Je peux vous dire que cela Fonctionne définitivement. Je suppose que vous dépensez beaucoup de temps à réfléchir à des noms de test parce que vous n'êtes pas assez confiant. Écrivez votre test en premier, mais laissez votre créativité débiter ...
J'ai remarqué qu'une fois que vous avez vraiment obtenu le hang de TDD, vous commencez à vous occuper un peu moins sur "Comment vais-je nommer ce test ... ARGH!", Et vous passez juste avec elle, refactoring et adaptation déjà écrite tests pour adapter la situation actuelle.
Temps pour une pointe
Conseil n ° 1
Donc, la pointe que je pense devrait vous aider le plus, c'est ne pas tellement vous inquiéter. L'une des plus jolies choses à propos de TDD est qu'elle vous donne du courage de changer de choses déjà écrites et de travail. Et cela inclut les tests.
Conseil n ° 2
Commencez de nouveaux tests de classe par un simple test "CANCREATE", juste pour vous mettre en tête dans la bonne direction, comme dans "OK, je travaille sur cette classe maintenant ..."
Ensuite, commencez à ajouter plus de tests, mais une seule à la fois et assurez-vous que chaque test que vous créez, c'est le cas le plus simple suivant qui vous aboutit à ce point (y penser plus de 30 secondes, puis du délai d'attente avec le mieux que vous avez à ce moment-là).
Et rappelez-vous
Ne vous inquiétez pas de refactoriser les tests existants ni même de retirer des tests obsolètes ou redondants. Peu de gens ne réalisent pas cela, mais dans TDD, vous obtenez 2 filets de sécurité pour le prix de 1. Vos tests sont un réseau de sécurité pour les changements de code de production, mais votre code de production est également un filet de sécurité pour refactoriser les tests. La relation est mutuelle. C'est en fait un bon cas d'accouplement serré.
Donnez-lui un autre coup. Et laissez-moi vous recommander de regarder Clean Code CastSs , en particulier celles de TDD.
Exemple non trivial du monde réel:
Je devais écrire une fonction de transformation de la structure de données. L'entrée serait une structure de données (une structure de données imbriquée, un peu comme un arbre) et la sortie constituerait une structure de données similaire. Je ne pouvais pas visualiser la transformation réelle dans mon esprit. Un des principaux avantages de TDD (pour moi, de toute façon) est l'application des étapes pour bébé si vous ne savez pas comment procéder (voir Kent Becks "TDD par exemple"). Parce que je ne savais pas où cela allait, j'ai commencé avec les cas de base simples tels que des intrants vides ou triviaux et a travaillé jusqu'à mes études plus compliquées jusqu'à ce que je fous, je les avais tous couverts. En fin de compte, j'ai eu un algorithme de travail et les tests qui l'ont prouvé. Non seulement les tests prouvent que ma mise en œuvre fonctionne actuellement, elles me empêchent également de viser quelque chose de plus tard. En raison du test de conduite de la mise en œuvre, il est découplé et l'API est propre.