Je travaille dans une grande entreprise, mais sur une équipe de deux personnes seulement qui développe des applications LOB de bureau. Je fais des recherches sur TDD depuis un certain temps maintenant, et bien qu'il soit facile de réaliser ses avantages pour les applications plus grandes, j'ai du mal à justifier le temps de commencer à utiliser TDD à l'échelle de nos applications.

Je comprends ses avantages dans l'automatisation des tests, l'amélioration de la maintenabilité, etc., mais à notre échelle, l'écriture même de tests unitaires de base pour tous nos composants pourrait facilement doubler le temps de développement. Étant donné que nous sommes déjà minés par des délais extrêmes, je ne sais pas quelle direction prendre. Bien que d'autres pratiques telles que le développement itératif agile soient parfaites depuis, je suis en quelque sorte déchiré par les compromis de productivité de TDD au sein d'une petite équipe.

Les avantages de TDD valent-ils le temps de développement supplémentaire sur de petites équipes avec des horaires très serrés?

La vilaine vérité est qu'au début, cela vous ralentira . Tout nouveau processus ou pratique prend du temps à se développer. D'après mon expérience, TDD ne paie pas autant avec la mise en œuvre initiale qu'avec la maintenance, la correction des bogues et l'extension. Je sais que pour d'autres, il y a un paiement immédiat, donc cela dépendra du style de codage actuel de chaque personne.

Bien que je sois un grand partisan du TDD (je l'ai apporté à mon emploi actuel), je pense que vous devez avoir un peu de marge de manœuvre (délais / délais) afin d'explorer et de comprendre la pratique.

Plus votre équipe est petite, plus vous pouvez bénéficier immédiatement du TDD. J'ai vu ce paiement en taille d'équipe de 6 à 3.

Le temps de développement supplémentaire dont vous parlez peut être une illusion .

Ce qui rend TDD différent des tests unitaires standard, c'est qu'il n'est pas seulement utilisé pour effectuer des tests.

TDD is a new way of developing software. C'est l'un des meilleurs moyens que je connaisse.

Par conséquent, il n'est pas lié à la taille de votre projet. Vous extrairez les avantages de la première ligne de code .

• cela vous obligera à structurer votre code de manière à être plus facile à maintenir et à réutiliser. Il pilote la conception de votre logiciel.
• cela rendra le refactoring rapide, sécurisé et agréable.
• il vous aide à écrire de plus petits morceaux de fonctionnalités qui facilitent beaucoup la mise en œuvre des tâches.
• cela rend généralement la tâche de débogage moins fréquente.

idée fausse commune, permettez-moi de le crier:

LES TESTS EN TDD SONT POUR LES CARACTÉRISTIQUES

MOE.

Edit: laissez-moi élaborer: "écrire ... des tests unitaires pour tous ou nos composants" est un test unitaire , pas TDD. J'utilise régulièrement TDD sur des équipes individuelles avec beaucoup de succès; le gain est extraordinaire.

Il y a un grand livre sur TDD, L'art des tests unitaires ( site officiel ) qui a ses exemples en .net avec une version java sur les travaux. La bonne partie est qu'il y a des chapitres entiers qui examinent des questions telles que "Intégrer les tests unitaires dans l'organisation" - Chapitre 8 et "Travailler avec le code hérité" - Chapitre 9. Bien que je ne sois pas un expert dans ce domaine (encore :-)) , d'après mon expérience, je pense que c'est un bon point de départ.

Il y a quelques questions dont vous avez besoin pour obtenir les réponses:

1. Combien de temps passez-vous après la publication de la correction d'un bug dans le code? Si vous pouvez quantifier cela, vous pourriez constater qu'il est égal ou même supérieur au temps "supplémentaire" qu'il vous faudrait pour écrire le test qui aiderait à empêcher ces bogues de se produire.

2. À quelle fréquence une modification apparemment simple pour refactoriser le code ou ajouter une nouvelle fonctionnalité a-t-elle cassé quelque chose d'apparemment sans rapport? Encore une fois avec une bonne couverture de test, ceux-ci peuvent être réduits.

Même si vous ne pouvez pas chiffrer ces chiffres, vous devriez être en mesure de démontrer que vous passez ce temps de toute façon, alors vous pourriez aussi bien le dépenser "d'avance" et (espérons-le) vous retrouver avec un produit beaucoup plus stable.

Lorsque les gens me parlent de commencer à adopter les tests dans leur équipe, je vérifie toujours d'abord comment les tests seront exécutés. Souvent, les équipes n'ont pas de structure continue en place. Si vous avez des ressources limitées, je dirais que la configuration d'un serveur CI est une condition préalable pour commencer toute incursion sérieuse dans les tests.

Une fois que vous avez cette configuration, commencez simplement à pratiquer le TDD. Gardez à l'esprit que si le système n'a pas été développé avec des tests à l'esprit, vous pourriez avoir du mal à rendre le code existant testable, et il sera coûteux de le restructurer.

Commencez par chercher des endroits faciles pour commencer avec TDD - de nouvelles classes ou modules, avec peu de dépendances. Les classes d'utilité et les structures de données sont souvent de bonnes choses pour commencer.

Obtenez une idée de la façon dont il change la façon dont vous pensez de votre code, notez à quel point le code que vous produisez est meilleur et combien vous êtes plus confiant à propos de ce code.

Je sais que je n'ai pas vraiment répondu à la question, mais je pense que mon point est que vous devriez être en mesure de faire tout cela sans coût supplémentaire énorme. En travaillant à travers vos premiers exemples, vous comprendrez mieux les avantages de votre projet.

Conclusion - développement plus lent, mais peu de défauts, donc moins de temps pour corriger les bugs.

Voici où je pense que le développement piloté par le comportement montre des gains immédiats, mais je ne suis pas sûr que le développement piloté par le test le fasse.

Dans le développement axé sur le comportement, vous abordez vos tickets d'une manière différente: vous vous asseyez avec l'homme d'affaires et travaillez avec lui pour définir les comportements que ce bloc de fonctionnalités doit avoir. Je décris cela dans une entrée sur mon blog, (le titre du message: Comportements d'écriture ).

S'asseoir avec l'homme d'affaires ou toute personne qui vous aidera à mieux comprendre ce que le système doit faire pour que tout le monde soit satisfait de cette fonctionnalité. Ce qu'il doit faire pour pouvoir être accepté par le processus d'AQ que vous avez en place.

La définition de critères de test, puis l'écriture de ces critères de test dans votre suite de tests automatisée, devrait réduire la quantité de va-et-vient que vous obtenez: quelqu'un qui prétend que la fonctionnalité est cassée, parce que vous avez manqué quelque chose (soit parce que vous avez légitimement manqué quelque chose, soit parce qu'ils ne l'ont jamais dit vous à ce sujet).

Cela peut également aider les autres à percevoir votre équipe: si vous vous asseyez et définissez ce qui doit être fait dans le système, vous pouvez passer de "des idiots qui surinventent tout et passent du temps sur des choses que nous n'avons pas demandées", à, "les gens intelligents qui proposent des fonctionnalités utiles".

TL; DR: Le développement basé sur le comportement peut montrer des améliorations rapidement car il est axé sur le «client». Le développement piloté par les tests, pour moi, semble consister à tester les composants internes de la base de code dont "personne" ne se soucie et qui offre des avantages commerciaux moins évidents. (Behaviour Driven Development a le changement immédiat, dans votre visage: les ingénieurs ont soudainement beaucoup plus de temps avec le «client» ou l'analyste commercial pour essayer de faire les choses correctement - ce qui devrait être considéré comme une bonne chose. »Oh , ils ont une réunion sur Feature X, ce qui signifie qu'il y a des progrès sur ce front! ")