Je travaille sur un projet où nous n'avons que 13% de la couverture de code avec nos tests unitaires. J'aimerais proposer un plan pour améliorer cela, mais en vous concentrant d'abord sur les zones où la couverture croissante apporterait la plus grande valeur. Ce projet est en C #, nous utilisons VS 2008 et TFS 2008 et Sortir des tests unitaires sont écrits à l'aide de Mstest.
Quelle méthodologie devrais-je utiliser pour déterminer quelles classes nous devrions aborder d'abord? Quelles métriques (code ou utilisation) devrais-je regarder (et comment puis-je obtenir ces métriques si cela n'est pas évident)?
5 Réponses :
Je recommanderais d'ajouter des tests d'unité à toutes les classes que vous touchez et non de la modernisation des classes existantes.
La plupart des avantages du test de l'unité consiste à aider les programmeurs à coder et à veiller à ce que des "corrections" ne cassent rien, si vous n'ajoutez pas de code à une nouvelle section de code qui n'est pas modifiée, les avantages de Les tests d'unités commencent à déposer.
Vous voudrez peut-être aussi ajouter des tests d'unité aux classes que vous comptez sur si vous n'avez rien de mieux à faire.
Vous devez absolument ajouter des tests à de nouvelles fonctionnalités que vous ajoutez, mais vous devez probablement ajouter des tests aux fonctionnalités existantes que vous pouvez casser.
Si vous faites un gros refacteur, envisagez d'obtenir une couverture de 80 à 100% sur cette section en premier.
La plus grande valeur d'un test d'unité est pour la maintenance, afin de garantir que le code fonctionne toujours après des modifications.
Ainsi, concentrez-vous sur des méthodes / classes les plus probables / les plus fréquemment changés.
Suivant en importance sont des cours / méthodes avec une logique moins que évidente. Les tests de l'unité les rendront moins fragiles tout en servant de "documentation" supplémentaire pour leur API sous contrat
Connaissez-vous un moyen de déterminer quelles classes sont les plus fréquemment changées? Pas sûr si je peux obtenir ce formulaire d'information TFS
Il s'agit davantage de connaissances sur le domaine des entreprises que de connaissances techniques, mais une bonne approximation peut être trouvée à partir de vos journaux du système de contrôle source.
Pour de bonnes statistiques et une interrogation déterministe de certaines méthodes, vous pouvez certainement regarder Ndepend: http: //www.ndepend .com /
NDEPEND expose une langue de requête appelée CQL (langue de requête de code) qui vous permet d'écrire des requêtes par rapport à votre code concernant certaines statistiques et une analyse statique.
Il n'y a pas de moyen VRAI de déterminer quelles classes pourraient bénéficier le plus, cependant, en définissant vos propres seuils dans la CQL, vous pouvez établir certaines règles et conventions.
organiser tous vos composants en niveaux. Chaque classe d'un niveau donné ne doit dépendre que des composants à un niveau inférieur. (Un "composant" est un groupe logique d'une ou plusieurs classes.)
Ecrire des tests d'unité pour tous vos composants de niveau 1 en premier. Vous n'avez généralement pas besoin de cadres moqueurs ou d'autres autres non-sens, car ces composants ne comptent que sur la framework .NET.
Une fois le niveau 1 terminé, commencez au niveau 2. Si vous niveautez, les tests de niveau 1 sont bons, vous n'aurez pas besoin de se moquer de ces classes lorsque vous écrivez vos tests de niveau 2.
Continuez dans la mode, en fonction de votre cheminement de la pile d'applications.
Conseil: casser tous vos composants dans des DLL spécifiques de niveau. De cette façon, vous pouvez vous assurer que les composants de faible niveau ne prennent pas accidentellement une dépendance sur un composant de niveau supérieur.
Dans les tests d'unités générales, un outil permettant de protéger contre la régression et la régression est le plus susceptible de se produire dans des classes avec la plus grande dépendance. Vous ne devriez pas avoir à choisir, vous devriez tester toutes les classes, mais si vous devez, testez les classes qui ont la plus grande dépendance en général.
Le choix n'est pas celui qui sera testé et lesquels ne seront-ils pas, mais qui envisageront le temps qu'il nous faudra pour obtenir toutes les classes testées, je veux savoir où commencer. Merci pour les commentaires précieux
+1 Je me débats avec exactement la même question.
Il est difficile de répondre précisément, mais la zone fondamentale de l'application devrait avoir des tests unitaires.