Quels sont les frais généraux réels de TDD une fois que toute l'équipe y est habituée?

Quel pourcentage de temps est économisé et coûte en faisant TDD.

J'assume ce pourcentage des changements de coûts et de récompenses au cours du cycle de vie d'un projet.

J'imagine que la phase initiale a beaucoup plus de coûts mais peu de récompenses. Plus loin (lors de la refactorisation ) vous bénéficiez de vos tests.

J'ai entendu de 30 à 50% de votre temps à écrire des tests unitaires. Cependant, cela ne prend pas en compte le temps gagné à écrire ces tests.

Quelle est l'expérience de chacun avec cela?

Nous s

MODIFIER Quel est le gain de temps ainsi que le coût en temps? Dans la correction de bugs et la refactorabilité?

J'ai entendu de 30 à 50% de votre temps à écrire des tests unitaires. Mais cela ne prend pas en compte le temps gagné

D'après mon expérience, c'est plus de 50%.

Une fois que vous avez passé le test, la solution a tendance à venir très facilement. Je ne pense donc pas qu'il soit étrange de passer de 70% à 75% de votre temps à écrire des tests, mais vous passez beaucoup moins de temps à écrire le `` code de production '' (code en cours de test) et vous ne passez pratiquement pas de temps dans le débogueur .

Plus tôt vous trouvez un bogue, moins cher il est à corriger, et TDD aide énormément à cela. J'ai travaillé sur des projets où les 2 derniers mois (d'un projet de 8 mois) ont été consacrés à la correction de bugs, et cette phase serait presque entièrement éliminée avec TDD.

Pour moi cependant, la vraie valeur réside dans la maintenance. Hériter d'une base de code avec des tests vous fait moins peur de la modifier. Vous avez l'impression de ne rien casser lorsque les tests réussissent. Puisque vous n'avez pas peur de faire des changements, vous êtes prêt à refactoriser si quelque chose ne va pas. Ce qui signifie que le code peut être rendu plus propre, la conception peut mieux s'adapter et, en théorie, des changements peuvent être appliqués. Comparez cela avec le code vaudou que tout le monde a peur de toucher.

Chaque fois que vous exécutez vos tests unitaires, vous vous économisez le temps qu'il aurait fallu pour tester manuellement votre code.

Les 30% à 50% du temps que vous citez comme étant requis pour écrire vos tests sont également largement compensés par les avantages d'avoir une meilleure conception logicielle (testable).

Disons qu'il faut quatre fois plus de temps pour écrire un test automatisé que pour effectuer manuellement le test. Cela signifie que la quatrième fois que vous exécutez votre test automatisé, il est rentable. Chaque fois que vous exécutez le test automatisé après cela, c'est gratuit.

Cela est vrai que le test soit un test unitaire automatisé ou un test fonctionnel automatisé. Tous les tests fonctionnels ne peuvent pas être automatisés, mais beaucoup d'entre eux le peuvent. De plus, le test automatisé est plus fiable qu'une personne; il exécutera le test exactement de la même manière , à chaque fois.

Avoir des tests unitaires signifie que vous pouvez refactoriser l'implémentation sous-jacente d'une méthode (pour des raisons de performances ou autres), et les tests unitaires vérifieront que la fonctionnalité de la méthode n'a pas changé. Cela est particulièrement vrai pour TDD, où le test unitaire spécifie la fonctionnalité de la méthode.

Le TDD est souvent mesuré en fonction de la qualité du code plutôt que du temps et des coûts dépensés. Cependant, avec une meilleure qualité de code, les développeurs et toutes les personnes travaillant avec eux peuvent mieux travailler (moins de temps passé, moins de coûts impliqués, plus heureux, etc.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

La rédaction de tests est idéale pour automatiser la vérification des exigences fonctionnelles et non fonctionnelles. Une vidéo qui m'a convaincu d'adopter TDD (en fait BDD, TDD de haut niveau): http://video.google.com/videoplay?docid=8135690990081075324#

• L'écriture de tests fonctionnels peut aider à repérer les bogues / problèmes plus tôt pendant la phase de développement . Supposons que vous ayez une grande base de code. Avec les tests unitaires / spécifications , il vous suffit de voir "Tous les tests réussis" / "2 tests ont échoué, voir la ligne xyz". Vous n'avez besoin que d' une équipe de développeurs pour effectuer à la fois le développement et les tests. Sans tests unitaires / spécifications , vous devez comparer manuellement les instructions imprimées avec les instructions attendues et tracer manuellement les méthodes / classes présentant des bogues. Vous aurez probablement besoin de deux équipes distinctes (développeurs et testeurs) pour ce faire.

• Des tests écrits aident les développeurs à expliquer les progrès et les problèmes rencontrés.

• TDD aide à assurer la maintenabilité, l'adaptabilité et la flexibilité du code. Il encourage les développeurs à écrire de petits morceaux testables et à les regrouper en plus gros morceaux testables. L'inverse (qui fait partie de la pratique du refactoring) fonctionne également, à condition d'avoir écrit des tests solides. En conséquence, nous pouvons avoir un code modulaire bien écrit.

Avec TDD, nous sommes heureux de savoir quand:

• un client demande des changements sur les exigences (satisfaire les exigences)
• de meilleures façons d'écrire du code sont découvertes
• les coéquipiers ont des suggestions pour l'amélioration du code
• nous devons expliquer / transmettre notre code à d'autres personnes

TDD peut être ennuyeux parce que le processus de développement prend de petites étapes, et donc il devient tellement prévisible.

Dans notre cas, je dirais que c'est près de 40%. Cependant, je ne pense pas que nous soyons passés par une phase où c'était plus que cela. Nous avons un générateur de code qui crache à la fois un squelette de code qui est étoffé par les développeurs et une suite de tests qui est également étoffée. La plupart de nos efforts de test vont en fait à la recherche (ou à la création) de données de test appropriées pour garantir une couverture complète.

les mesures à long terme importantes ne sont pas seulement la qualité du code et la confiance du code, mais même plus de ne pas épuiser l'équipe qui effectue des tests insensés

les mesures à court terme seraient le retour sur investissement de l'automatisation des tests

par exemple: la semaine dernière, j'ai effectué plus de 1000 modifications de code en raison d'un changement d'architecture interne, j'ai démarré la suite de tests automatisés et je me suis endormi.

les tests ont duré 28 minutes; ils sont tous passés. effectuer manuellement les mêmes 40+ tests d'acceptation prendrait environ 6 heures.

un autre exemple: dans une itération précédente, j'avais raté l'un des scénarios de test avec un bug subtil que les tests manuels n'auraient probablement pas trouvé (les tests automatisés effectuent des vérifications d'intégrité de base de données que les testeurs manuels ne font presque jamais). j'ai dû exécuter ce scénario de test environ 50 fois avant de réussir à le comprendre et à le réparer. l'exécution manuelle des opérations du scénario de test prendrait environ 50 minutes. Cela représente donc 41,6 heures de travail économisées en une journée

il n'y a aucun moyen de calculer à l'avance le retour sur investissement des tests automatisés, car vous ne pouvez pas savoir exactement combien de fois vous devrez exécuter les tests.

mais pour moi, le retour sur investissement des tests automatisés est presque infini

Il peut être très utile de restreindre les tests unitaires à des algorithmes complexes, aux cas où ils peuvent être générés automatiquement et aux régressions.

Les tests de composants font souvent un excellent travail pour du code plutôt trivial, et changer l'implémentation est beaucoup moins cher car les tests ne sont couplés qu'à l'interface.

Une couverture complète avec des tests unitaires à grain fin a un énorme surcoût pour changer ou refactoriser une implémentation, ce qui est exactement ce qu'ils prétendent rendre facile.