Quelles sont les raisons pour lesquelles un développeur unique devrait utiliser le TDD ?

Question

Je suis un programmeur contractuel avec beaucoup d'expérience. J'ai l'habitude d'être engagé par un client pour réaliser un projet de logiciel d'une forme ou d'une autre par moi-même, généralement à partir de rien. Cela signifie que je fais table rase du passé, presque à chaque fois. Je peux apporter des bibliothèques que j'ai développées pour démarrer rapidement, mais elles sont toujours facultatives. (et dépendent de l'inclusion des bonnes clauses de propriété intellectuelle dans le contrat). matériel informatique plateforme... donc nous parlons de liberté sérieuse ici.

Je peux voir des utilisations pour construire des tests automatisés pour certains codes : Les bibliothèques avec des fonctionnalités plus que triviales, les fonctionnalités de base avec un nombre élevé de références, etc. En gros, comme la valeur d'un morceau de code augmente en raison d'une utilisation intensive, je peux voir qu'il serait de plus en plus utile de tester automatiquement ce code afin de savoir si je ne le casse pas.

Cependant, dans ma situation Je trouve difficile de rationaliser plus que cela. J'adopterai des choses si elles s'avèrent utiles, mais je ne suis pas prêt à suivre aveuglément quoi que ce soit.

Je trouve que beaucoup de choses que je fais dans le cadre de la "maintenance" sont en fait de petits changements de conception. Dans ce cas, les tests ne m'auraient rien épargné et il faudrait maintenant les modifier aussi. Une approche de conception hautement itérative et axée sur le stub fonctionne très bien pour moi. Je ne vois pas comment je pourrais gagner autant de temps avec des tests plus poussés.

Les projets de loisir sont encore plus difficiles à justifier... ils durent généralement entre un week-end et un mois. Les bogues marginaux sont rarement importants, il s'agit de jouer avec quelque chose.

Lire des questions telles que celui-ci La réponse la plus votée semble dire que, d'après l'expérience/opinion de l'auteur de l'article, la TDD fait perdre du temps à moins de 5 personnes (même en supposant un certain niveau de compétence/expérience de la TDD). Cependant, cela semble couvrir le temps de développement initial, et non la maintenance. Il n'est pas clair comment la TDD se positionne sur l'ensemble du cycle de vie d'un projet.

Je pense que TDD pourrait être une bonne étape dans l'objectif louable d'améliorer la qualité des produits de notre industrie dans son ensemble. L'idéalisme en soi n'est plus aussi efficace pour me motiver, cependant.

I faire Je pense que la TDD serait une bonne approche pour les grandes équipes, ou pour toute équipe contenant au moins un programmeur peu fiable. Ce n'est pas ma question.

Pourquoi un développeur unique ayant de bons antécédents adopterait-il le TDD ?

J'aimerais entendre parler de toute sorte de mesures effectuées (officiellement ou non) sur la TDD... en se concentrant sur les développeurs solos ou les très petites équipes.

À défaut, des anecdotes sur vos expériences personnelles seraient également les bienvenues :)

Veuillez éviter d'énoncer des opinions sans expérience pour les étayer. N'en faisons pas une guerre d'idéologie. Egalement l'argument de l'abandon des options d'emploi. Il s'agit simplement d'une question d'efficacité.

Answer 1

Je ne suis pas prêt à suivre aveuglément quoi que ce soit.

C'est la bonne attitude. J'utilise TDD tout le temps, mais je n'y adhère pas aussi strictement que certains.

Le meilleur argument (à mon sens) en faveur de la TDD est que vous obtenez un ensemble de tests que vous pouvez exécuter lorsque vous arrivez enfin aux phases de remaniement et de maintenance de votre projet. Si c'est la seule raison pour laquelle vous utilisez TDD, alors vous pouvez écrire les tests quand vous le souhaitez, au lieu de suivre aveuglément la méthodologie.

L'autre raison pour laquelle j'utilise le TDD est que l'écriture de tests m'amène à réfléchir à mon API dès le départ. Je suis obligé de penser à la façon dont je vais utiliser une classe avant de l'écrire. Cela me permet de me plonger dans le projet à un niveau aussi élevé. Il existe d'autres façons de procéder, et si vous avez trouvé d'autres méthodes (il y en a beaucoup) pour faire la même chose, alors je vous dirais de continuer à faire ce qui fonctionne pour vous.

Answer 2

Je le trouve encore plus utile lorsque je vole en solo. Sans personne autour de vous pour faire rebondir les idées et sans personne autour de vous pour effectuer des évaluations par les pairs, vous aurez besoin de l'assurance que votre code est solide. TDD/BDD vous fournira cette assurance. TDD est un peu controversé, cependant. D'autres peuvent être en total désaccord avec ce que je dis.

EDIT : J'ajouterai que si l'on s'y prend bien, on peut en fait générer les spécifications de son logiciel en même temps que l'on écrit les tests. C'est un excellent effet secondaire de BDD. Vous pouvez vous faire passer pour un super développeur si vous produisez un code solide en même temps que les spécifications, tout seul.

Answer 3

Ok mon tour... Je ferais TDD même sur mon propre (pour le code non-spike/expérimental/prototype) parce que

• Réfléchissez avant de vous lancer Cela m'oblige à réfléchir à ce que je veux faire avant de commencer à écrire du code. Qu'est-ce que j'essaie d'accomplir ici 'Si je suppose que j'ai déjà cette pièce comment est-ce que je m'attends à ce qu'elle fonctionne?' Encourage l'interface dans la conception des objets.
• Plus facile à changer : Je peux faire des modifications en toute confiance Je n'ai rien cassé dans les étapes 1 à 10 lorsque j'ai modifié l'étape 5. Le test de régression est instantané
• De meilleures conceptions émergent : J'ai constaté que de meilleures conceptions émergeaient sans que j'investisse des efforts dans une activité de conception. test-first + Refactoring conduisent à des classes peu couplées, minimales avec des méthodes minimales pas de suringénierie pas de code YAGNI. Les classes ont de meilleures interfaces publiques, de petites méthodes et sont plus lisibles. C'est un peu comme un truc zen vous ne remarquez que vous l'avez obtenu quand vous l'avez "obtenu".
• Le débogueur n'est plus ma béquille. : Je sais ce que fait mon programme sans avoir à passer des heures à parcourir mon propre code. Aujourd'hui, si je passe plus de 10 minutes avec le débogueur les alarmes mentales commencent à sonner.
• m'aide à rentrer chez moi à l'heure J'ai remarqué une nette diminution du nombre de bogues dans mon code depuis TDD même si l'assert est comme une trace Console et non un AT de type xUnit.
• Productivité / Flux Le TDD : il m'aide à identifier la prochaine petite étape discrète qui me mènera à la réalisation... la boule de neige continue de rouler. TDD m'aide à entrer dans un rythme (ou ce que les XPers appellent flow) plus rapidement. J'obtiens une plus grande part de travail de qualité par unité de temps qu'auparavant. Le cycle rouge-vert-réfactor se transforme en... une sorte de machine à mouvement perpétuel.
• Je peux prouver que mon code fonctionne en appuyant sur un bouton
• La pratique rend parfait Je trouve que j'apprends et repère les dragons plus rapidement... avec plus de temps TDD à mon actif. Peut-être une dissonance... mais j'ai le sentiment que la TDD a fait de moi un meilleur programmeur même si je ne teste pas en premier. Repérer les opportunités de refactoring est devenu une seconde nature...

Je mettrai à jour si j'en trouve d'autres. C'est ce que j'ai trouvé dans les 2 dernières minutes de réflexion.

Answer 4

Je suis aussi un programmeur contractuel. Voici mes 12 raisons pour lesquelles j'aime les tests unitaires .

Answer 5

Il importe peu que vous soyez le seul développeur ou non. Vous devez y penser du point de vue de l'application. Toutes les applications doivent fonctionner correctement, toutes les applications doivent être maintenues, toutes les applications doivent être moins boguées. Il existe bien sûr certains scénarios dans lesquels l'approche TDD ne vous convient pas. C'est le cas lorsque la date limite approche très vite et que vous n'avez pas le temps d'effectuer des tests unitaires.

Quoi qu'il en soit, le TDD ne dépend pas d'un environnement solo ou d'une équipe. Elle dépend de l'application dans son ensemble.