Est-il possible d'introduire le Test Driven Development (TDD) dans un projet mature?

Question

• Disons que nous avons réalisé une valeur de TDD trop tard. Le projet est déjà à maturité, beaucoup de clients ont commencé à l'utiliser.
• Dire de tests automatisés utilisés sont généralement fonctionnel/système de test et il y a une bonne affaire de automatisé GUI tests.
• Dire que nous avons des nouvelles demandes de fonctionnalités, et de nouveaux rapports de bug (!). Si bon nombre de projets de développement se poursuit encore.
• Remarque, il y aurait déjà beaucoup d'objet de l'entreprise avec peu ou pas de tests unitaires.
• Trop de collaboration et les relations entre eux, ce qui est encore testé uniquement par le biais de niveau supérieur fonctionnels et les tests du système. Pas de tests d'intégration en soi.
• De grandes bases de données en place avec beaucoup de tables, de vues, etc. Juste pour instancier un seul objet, il y a déjà une bonne partie de la base de données allers-retours.

Comment pouvons-nous introduire TDD à ce stade?

Se moquant semble être la voie à suivre. Mais le montant de se moquer de nous devons faire ici semble comme trop. Sonne comme infrastructure élaborée doit être développé pour les moqueries système de travail pour les trucs (BO, bases de données, etc.).

Est-ce à dire TDD est une méthodologie adaptée uniquement lors du démarrage à partir de zéro? Je suis intéressé à entendre parler de la faisabilité des stratégies pour introduire TDD dans un produit à maturité.

Answer 1

La création d'un complexe se moquant de l'infrastructure sera probablement juste de masquer les problèmes dans votre code. Je vous recommande de commencer avec les tests d'intégration, avec une base de données de test, autour de toutes les zones de la base de code que vous l'intention de changer. Une fois que vous avez suffisamment de tests pour s'assurer que vous ne cassez rien, si vous faites un changement, vous pouvez commencer à refactoriser le code pour le rendre plus testable.

Voir aussi Michael Plumes excellent livre de Travailler de façon efficace avec le code existant, c'est une lecture incontournable pour tous ceux qui envisagent d'introduire TDD dans un héritage de la base de code.

Answer 2

Je pense que c'est tout à fait faisable à introduire TDD dans une application existante, en fait, j'ai récemment fait moi-même.

Il est plus facile à coder de nouvelles fonctionnalités dans un TDD manière et de la restructuration du code existant pour le permettre. De cette façon, vous commencez avec une petite section de votre code testé, mais les effets commencent à se répandre dans l'ensemble de la base de code.

Si vous avez un bug, puis d'écrire un test unitaire pour le reproduire, refactoring du code (à moins que l'effort en vaut vraiment pas la peine).

Personnellement, je ne pense pas qu'il soit besoin d'aller fou et d'essayer de la rénovation des tests dans le système existant car cela peut être très fastidieux sans un grand montant de la prestation.

En résumé, commencer petit et de votre projet va devenir de plus en plus de tests infectés.

Answer 3

Oui, vous pouvez. À partir de votre description le projet est dans une bonne forme solide quantité de tests fonctionnels de l'automatisation est un chemin à parcourir! Dans certains aspects de son encore plus utile que les tests unitaires. Rappelez-vous que TDD != les tests unitaires, il est tout au sujet des itérations courtes et solides, les critères d'acceptation.

Rappelez-vous que le fait d'avoir un projet accepté, en fait facilite les tests de travail de l'application est la meilleure spécification des exigences. Si vous êtes dans une meilleure position que quelqu'un qui vient d'avoir un bout de papier pour travailler avec.

Venez de commencer à travailler sur vos nouvelles exigences/corrections de bugs avec un ATS. Rappelez-vous qu'il y aura des frais généraux associés à un transfert de la méthodologie (assurez-vous que vos clients sont au courant de cela!) et sans doute s'attendre à une bonne partie de la réticence des membres de l'équipe qui sont utilisés pour le "bon vieux" façons.

Ne touchez pas les vieilles choses, à moins que vous en avez besoin. Si vous avez une demande d'amélioration qui va avoir des répercussions sur les choses, puis facteur dans le temps additionnel pour en faire une supplémentaire choses.

Personnellement, je ne vois pas beaucoup de valeur dans l'introduction d'une infrastructure complexe pour maquettes- il y a sûrement un moyen d'atteindre les mêmes résultats dans un mode léger, mais cela dépend évidemment de votre situation

Answer 4

Un outil qui peut vous aider de tests de code legacy (en supposant que vous ne pouvez pas\n'aurez pas le temps de refactoriser le code, est Typemock Isolateur: Typemock.com Il permet l'injection de dépendances dans le code existant sans avoir besoin d'extraire des interfaces et telle parce qu'elle n'utilise pas la norme des techniques de réflexion (dynamic proxy etc..), mais qui utilise le profiler les Api de la place. Il a été utilisé pour tester les applications qui s'appuient sur sharepoint, HTTPContext et d'autres zones à problèmes. Je vous recommande de prendre un coup d'oeil. (Je travail en tant que dev dans la société, mais c'est le seul outil qui ne doit pas vous forcer à refactoriser existants, héritage de code, vous permet d'économiser du temps et de l'argent) Je voudrais également fortement recommandé de "Travailler efficacement avec le code hérité" de plus en plus techniques.

Roy

Answer 5

Oui, vous pouvez. Ne pas tout faire à la fois, mais introduire juste ce dont vous avez besoin pour tester un module à chaque fois que vous le touchez.

Vous pouvez aussi commencer avec le plus haut niveau des tests d'acceptation et de travailler votre chemin à partir de là (jetez un oeil à Fitnesse pour cela).