On peut également, via l'onglet « Code Coverage », définir pour quelles DLLs nous mesurerons la couverture de code lors de l'exécution des tests.

Il suffit pour cela :

• De compiler la solution dans la configuration
• De cliquer sur l'onglet « Code Coverage », puis sur « Add Assembly » pour sélectionner la DLL souhaitée.

On pourra laisser les autres options par défaut.

Pour visualiser le résultat de la couverture de code, il suffit de faire un « clic droit » sur les résultats de tests, et de demander « Code Coverage Results ».

On pourra alors voir un résumé - pour tous les projets couverts - de la couverture de code, autorisant de descendre au niveau de chaque fonction.

Il sera alors possible de double cliquer sur une méthode, de façon à visualiser la partie de code qui est couverte (en bleu) et celle par laquelle aucun test ne passe (en rouge).

Attention cependant : si vous demandez dans votre fichier .testrunconfig de couvrir trois DLLs, mais que seules deux d'entre elles possèdent des tests unitaires, on pourrait logiquement s'attendre à que cette troisième DLL apparaissent dans le résultat de la couverture de code avec une couverture à 0%.
Cependant les DLLs couvertes à 0% n'apparaissent pas dans les résultats. Le pourcentage global de couverture de code peut donc s'avérer trompeur.

Je ne vais pas ici rentrer dans un débat sur le pourcentage de couverture de code à obtenir, mais je tenais à faire une courte mise en garde.

Si tous les experts s'accordent à dire qu'un projet couvert à 10% est objectivement un projet à risque, a contrario, un projet couvert à 80 ou 100% ne doit pas donner l'impression d'un projet sûr.

En effet une méthode couverte à 100% signifie uniquement que du code de test passe par toutes les branches possibles de la méthode. Cela ne garantit en rien que des assertions existent pour toutes les branches possibles.

Il faut davantage s'attarder sur la qualité et la pertinence des tests unitaires que de se fixer un taux arbitraire de couverture de code à atteindre.

Certains tests peuvent avoir besoin de ressources (fichier textes, scripts, .) lors de leur exécution. Il est possible via la configuration de définir des fichiers à déployer.

Pour cela, il suffit de se rendre dans l'onglet « Deployment » et de sélectionner « Add File » ou « Add Directory », tout en s'assurant bien sûr que la case à cocher « Enable deployment » est bien cochée.

 

A chaque fois que les tests s'exécutent, un répertoire avec le nom du « test run » est créé, avec à l'intérieur un répertoire « Out ».

Outre les différentes DLLs à tester, c'est ici que l'on retrouve les fichiers déployés.

Attention au nommage des fichiers et répertoires! Si vous demandez de déployer un répertoire, c'est ce répertoire au complet qui sera copié dans le répertoire « Out ».
Dans tous les cas, si vous déployez deux fichiers ou deux répertoires avec le même nom, l'un des deux sera perdu. Un simple avertissement dans un fichier de log vous avertira de votre erreur.

Notez que lors de l'ajout d'un répertoire, Visual Studio va automatiquement ajouter un « \ » à la fin du répertoire.

Dans les premières versions de Visual Studio 2005 (sans service pack), cela pouvait poser problème lors de l'exécution des tests, considérant que le fichier n'était pas valide. Si c'est le cas, il suffit d'éditer le testrunconfig en XML afin de supprimer le dernier « \ ».