Les générateurs de tests unitaires vous ont-ils aidé lors de l'utilisation de code hérité?

Je regarde une petite base de code C # (.NET 4.0, certains Silverlight) (~ 70kLOC générée) qui a une très faible couverture de test. Le code lui-même fonctionne en ce qu'il a réussi les tests d'acceptation des utilisateurs, mais il est fragile et dans certains domaines pas très bien pris en compte. Je voudrais ajouter une couverture de test unitaire solide autour du code hérité en utilisant les suspects habituels (NMock, NUnit, StatLight pour les bits Silverlight).

Mon approche normale est de commencer à travailler sur le projet, les tests unitaires et la refactorisation, jusqu'à ce que je sois satisfait de l'état du code. Je l'ai fait plusieurs fois dans le passé, et cela a bien fonctionné.

Cependant, cette fois, je pense utiliser un générateur de test (en particulier Pex ) pour créer le framework de test, puis l'étoffer manuellement.

Ma question est la suivante: avez-vous utilisé des générateurs de tests unitaires dans le passé lorsque vous avez commencé à travailler sur une base de code héritée, et si oui, les recommanderiez-vous?

Ma crainte est que les tests générés manqueront les nuances sémantiques de la base de code, conduisant à la situation redoutée d'avoir des tests pour le bien de la métrique de couverture, plutôt que des tests qui expriment clairement le comportement prévu dans le code.

unit-testing legacy

— Duncan Bayne
source

J'ai essayé PeX une fois et les résultats étaient, disons, pas très satisfaisants - YMMV. Ne vous attendez pas à ce qu'un tel outil "comprenne" votre code et ses exigences fonctionnelles - il ne manque pas seulement les "nuances sémantiques", il manque toute la sémantique. De plus, lorsque vous commencez avec une base de code héritée, vous ne commencez généralement pas par des tests unitaires en premier, mais par des tests système ou d'intégration; ce n'est certainement rien pour quoi PeX a été créé.

— Doc Brown

Je suggérerais de voir les choses un peu différemment. L'ajout d'un nouveau code de test unitaire à une application existante sans incident peut ne pas vous donner les meilleurs résultats. Si vous faites cela pour vous familiariser avec la base de code ou si vous avez vraiment le temps de tuer et que vous souhaitez tester les générateurs de test, ignorez mes commentaires.

Pour être pragmatique, vous devez parcourir toutes les listes de bogues. Créez ensuite des tests unitaires pour chacun des bogues, ce qui se traduit par la façon dont il doit se comporter. Idéalement, vous n'ajouteriez de nouveau code pour chaque bogue que lorsque vous l'atteindriez.

Temps pour ajouter le code de test unitaire:

Ajout de nouvelles fonctionnalités
Code remanié
Correction d'un bug
Apprendre ce que fait le code
Prouver qu'un bug existe

Il est difficile de quantifier la valeur de l'ajout de tests unitaires après coup.

Normalement, je ne me permets pas d'écrire des réponses qui vont à l'encontre de ce que le demandeur veut, mais je pense que c'est une bonne leçon à transmettre.

— Andrew T Finnell
source

Je suis à 100% d'accord avec vous là-bas - cette question est venue de moi me demandant comment mieux dépenser un certain temps d'arrêt. Ma pratique normale consiste à tester et à refactoriser le processus de correction de bogues ou d'ajout de fonctionnalités. J'espérais que certaines personnes pourraient partager des histoires de guerre dans ce domaine ...

— Duncan Bayne

+1, La prise de vue de la couverture après coup n'est généralement pas productive. Avoir des tests sur des bogues corrigés qui empêchent la régression est très productif. La régression d'un bug peut être très frustrante pour toutes les personnes impliquées. Les tests sont vraiment adaptés pour vous aider à écrire un meilleur code. Le boulonnage des tests aboutit généralement à des tests de qualité inférieure. Je pense que la peur de l'OP est fondée et le rapport signal / bruit des tests générés ne fera qu'empêcher. Le code non testé contient probablement des bits très branchés. Les outils qui signalent les odeurs de code sont probablement plus utiles. Peut-être FXCop et des outils similaires.

— kevpie