Est-il possible d'introduire le développement piloté par les tests (TDD) dans un projet mature? [fermé]

Question

• Disons que nous avons réalisé une valeur de TDD trop tard. Le projet est déjà mûri, beaucoup de clients ont commencé à l'utiliser.
• Supposons que les tests automatisés utilisés sont principalement des tests fonctionnels / système et qu'il existe de nombreux tests automatisés d'interface graphique.
• Disons que nous avons de nouvelles demandes de fonctionnalités et de nouveaux rapports de bogues (!). Il reste donc beaucoup de développement.
• Notez qu'il y aurait déjà beaucoup d'objet métier sans ou avec peu de tests unitaires.
• Trop de collaboration / relations entre eux, ce qui est encore testé uniquement par le biais de tests de fonctionnalité / système de niveau supérieur. Aucun test d'intégration en tant que tel.
• Des bases de données volumineuses sont en place, avec de nombreux tableaux, vues, etc. Il suffit déjà d'instancier un seul objet métier pour effectuer des allers-retours entre bases de données.

Comment pouvons-nous introduire le TDD à ce stade?

Se moquer semble être la voie à suivre. Mais la quantité de moqueries que nous devons faire ici semble être trop. Cela ressemble à une infrastructure élaborée qui doit être développée pour que le système de simulation s’applique aux éléments existants (BO, bases de données, etc.).

Est-ce que cela signifie que TDD est une méthodologie appropriée uniquement à partir de zéro? Je suis intéressé par les stratégies possibles pour introduire le TDD dans un produit déjà mature.

Answer 1

La création d’une infrastructure complexe de moquage masquera probablement les problèmes de votre code. Je vous recommanderais de commencer par des tests d'intégration, avec une base de données de tests, autour des zones de la base de code que vous prévoyez de modifier. Une fois que vous avez suffisamment de tests pour vous assurer de ne rien casser si vous apportez une modification, vous pouvez commencer à remanier le code pour le rendre plus testable.

Voir aussi Michael Feathers, excellent livre Travailler efficacement avec le code hérité , c’est un doit être lu par toute personne souhaitant introduire TDD dans une base de code héritée.

Answer 2

Je pense qu'il est tout à fait possible d'introduire TDD dans une application existante. En fait, je l'ai récemment fait moi-même.

Il est plus facile de coder de nouvelles fonctionnalités de manière TDD et de restructurer le code existant pour y répondre. De cette façon, vous commencez par tester une petite partie de votre code, mais les effets commencent à se propager à travers toute la base de code.

Si vous avez un bogue, écrivez un test unitaire pour le reproduire, refactorisez le code si nécessaire (à moins que l'effort n'en vaut vraiment la peine).

Personnellement, je ne pense pas qu'il soit nécessaire de devenir fou et d'essayer de moderniser les tests dans le système existant, car cela peut être très fastidieux sans beaucoup d'avantages.

En résumé, commencez petit et votre projet sera de plus en plus infecté par les tests.

Answer 3

Oui, vous le pouvez. D'après votre description, le projet est en bonne forme. De nombreux tests fonctionnels automatisés sont une voie à suivre! À certains égards, il est encore plus utile que les tests unitaires. Rappelez-vous que TDD! = Les tests unitaires sont des itérations courtes et des critères d’acceptation solides.

N'oubliez pas que le fait de disposer d'un projet existant et accepté facilite les tests - les applications en fonctionnement constituent la meilleure spécification requise. Vous êtes donc mieux placé que quelqu'un qui n'a qu'un bout de papier avec lequel travailler.

Commencez tout juste à travailler sur vos nouvelles exigences / corrections de bugs avec un TDD. N'oubliez pas qu'il y aura un temps système associé au changement de méthodologie (assurez-vous que vos clients en sont conscients!) Et attendez-vous probablement à une grande réticence des membres de l'équipe habitués aux «bonnes vieilles méthodes».

Ne touchez pas les vieilles choses sauf si vous en avez besoin. Si vous avez une demande d'amélioration qui aura une incidence sur les éléments existants, prenez en compte le temps supplémentaire nécessaire pour la configuration supplémentaire.

Personnellement, je ne vois pas l'intérêt d'introduire une infrastructure complexe pour les maquettes - il existe sûrement un moyen d'obtenir les mêmes résultats en mode allégé, mais cela dépend évidemment de vos circonstances

Answer 4

Typemock Isolator: Typemock.com est un outil qui peut vous aider à tester le code existant (en supposant que vous ne pouvez pas avoir le temps de le refactoriser. Il permet d'injecter des dépendances dans du code existant sans avoir à extraire d'interfaces, par exemple parce qu'il n'utilise pas les techniques de réflexion standard (proxy dynamique, etc.), mais utilise plutôt les API du profileur. Il a été utilisé pour tester des applications qui s'appuient sur SharePoint, HTTPContext et d'autres domaines problématiques. Je vous recommande de jeter un coup d'oeil. (Je travaille en tant que développeur dans cette société, mais c'est le seul outil qui ne vous oblige pas à refactoriser le code existant, ce qui vous permet d'économiser du temps et de l'argent) Je vous recommande également vivement de "travailler efficacement avec le code existant". pour plus de techniques.

Roy

Answer 5

Oui, vous le pouvez. Ne faites pas tout cela en même temps, mais introduisez ce dont vous avez besoin pour tester un module à chaque fois que vous le touchez.

Vous pouvez également commencer avec davantage de tests d'acceptation de haut niveau et descendre d'un niveau à l'autre (consultez Fitnesse pour cela).

Answer 6

Je commencerais par quelques tests d'intégration de base. Cela suscitera l'adhésion du reste du personnel. Commencez ensuite à séparer les parties de votre code qui ont des dépendances. Travaillez pour utiliser l’Injection de dépendance, car cela rendra votre code beaucoup plus testable. Traitez les bogues comme une opportunité d’écrire du code testable.