Je n'ai jamais utilisé de mécanisme de test automatisé dans aucun de mes projets et je sens que je manque beaucoup. Je veux m'améliorer, donc je dois commencer à résoudre certains problèmes que j'ai négligés comme ça et essayer Git au lieu de rester bloqué sur SVN.
Quelle est la bonne façon d'apprendre le TDD? J'utiliserai probablement Eclipse pour programmer en Java. J'ai entendu parler de JUnit, mais je ne sais pas s'il y a autre chose à considérer.
Réponses:
Vous pouvez commencer par travailler sur le codage des katas . Choisissez un algorithme (par exemple, conversion de nombres décimaux en chiffres romains, marquant une partie de bowling, le jeu de la vie de Conway, etc.) et essayez d'utiliser TDD pour travailler sur la solution.
La structure de votre solution sera probablement très simple (beaucoup plus simple que votre code de production réel): une classe pour le dispositif de test et une classe contenant l'algorithme testé. Et la classe testée n'ayant pas de dépendances est un autre avantage. Vous pouvez utiliser la simplicité de cette configuration pour vous familiariser rapidement avec la boucle rouge-vert-refactor.
L'outil que vous utilisez pour vos katas TDD n'a pas vraiment d'importance tant que vous respectez les principes. Cependant, le plugin JUnit pour Eclipse est très facile à utiliser, c'est donc un excellent choix.
Familiarisez-vous avec AAA , lisez-le, lisez les problèmes liés au développement piloté par les tests ( conception pour la testabilité vs outils à coût élevé pour que la conception n'ait pas d'importance). Apprenez l' injection de dépendances pour que la suppression des dépendances externes pour les tests devienne plus simple.
Voici un bon aperçu des notes que j'ai prises en lisant L'art des tests unitaires
http://imaginarydevelopment.blogspot.com/2010/01/unit-testing-reference.html
Il n'y a vraiment aucun substitut pour simplement attraper un harnais de test (comme NUnit), lire une partie de la littérature et ensuite se salir les mains.
Comme James T. Kirk l'a dit un jour: «Nous apprenons en faisant».
Je recommande fortement ce livre: faire croître un logiciel orienté objet guidé par des tests
Il contient un exemple concret qui parcourt le livre et fournit une vue très cohérente du moment où le test doit être créé, ce qu'il doit contenir et comment il doit être construit et refactorisé.
Vérifiez ce lien . C'est le blog de Bob Martin sur TDD - d'excellentes choses pour vous faire comprendre (ou vous donner une autre perspective) la réflexion sur TDD.