Lors d'un bon cycle ALM, il est important de s'intéresser à la couverture de code pour voir si notre stratégie de tests est bien configurée et si l'on se protège d'éventuels bugs qui auraient pu être détéctés au plus tôt.

C'est donc cette optique que certains de mes projets persos ont été inclus au sein de mon serveur TFS pour passer en intégration continue. Si tout se passait merveillement bien sur le serveur TFS (compilation, testing, coverage), il n'en n'était pas la même chose en local sur mon poste de développement. En effet, l'onglet Code Coverage m'indiquait un magnifique "Cannot find any coverage data (.coverage or .coveragexml) files."

la première raison fut que je n'avais pas configuré le code coverage pour mon projet. Pour cela, quelques étapes sont nécessaires:

1- Double-cliquez sur le fichier Local.testsettings situé au niveau de votre solution. (ou créez-le s'il est manquant)

2- Dans la partie gauche, cliquez "Data and diagnostics"

3- Cochez la case "Code Coverage"

4- Cliquez une fois sur la ligne Code Coverage afin d'activer le bouton "Configure" situé au dessus de la liste

5- Cliquez alors sur le bouton "Configure" afin d'ouvrir la liste des assemblies à tester

6- Cochez les assemblies de votre choix. Fermer tout en sauvegardant votre projet

7- Lancez les tests unitaires via le menu Test > Run > Tests in Current Context

8- Les résultats apparaissent alors dans la fenêtre Test > Windows > Code Coverage Results

SAUF QUE, parfois cela ne suffit pas et le message indiquant qu'aucun fichier de coverage n'est présent est toujours affiché. Et c'est là le problème car Visual Studio n'est alors d'aucune aide pour trouver l'origine du problème. L'indice se trouve en effet dans le journal des événements. Au sein de ce dernier, plusieurs erreurs liées à Visual dont une avec un message intriguant "The web.config file for the site http://localhost:0/ contains information from a previous run" et une seconde indiquant que l'accès au fichier web.config est refusé. Pour ce dernier, rien de plus simple, il suffit d'enlever le mode read-only du fichier mais pour le second, il faut enquêter.

Il semblerait que lors de l'ajout du projet à TFS, certains attributs soient ajoutés au fichier de configuration et que ceux-ci dérangent Visual Studio. Solution simple: les retirer.

il s'agit des lignes suivantes:

<appSettings>
    <add key="microsoft.visualstudio.teamsystems.aspnetdevserver:/" value="3311;True;3204;1" />
    <add key="microsoft.visualstudio.teamsystems.backupinfo" value="1;web.config.backup" />
</appSettings>

Supprimez-les donc, sauvegardez et relancez les tests unitaires

Et voilà, le code coverage est pleinement fonctionnel!!!

S'il y a bien une chose que l'on ne peut discuter, c'est bien les goûts et les couleurs, et en parlant de couleurs, nous parlerons ici des couleurs de l'éditeur de code de Visual Studio.

Je pense qu'une majorité des développeurs utilisent les couleurs par défaut de Visual Studio, et certains doivent peut-être changer deux trois paramètres, simplement pour retrouver les habitudes qu'ils auraient eu avec un autre éditeur. Les rares personnes (dont moi) qui ont essayé de pousser la personnalisation un peu plus loin, se sont souvent mordu les dents en obtenant un résultat soit non esthétique, soit tout simplement à l'origine de magnifique migraines.

Aujourd'hui, je vous partage un petit outil que j'avais déjà trouvé il y a de cela plusieurs mois et qui se propose de générer en un seul clic des thèmes entiers de couleurs complémentaires.

Cet outil en ligne et gratuit se trouve à l'adresse suivante: Visual Studio Theme Generator

Voici le résultat d'un thème de base. On aime ou on aime pas mais personnellement, je m'y suis habitué rapidement, et je trouve ce thème moins fatiguant pour les yeux qu'un thème à fond blanc.

Libre à vous d'essayer :)