Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis

L'écriture de tests unitaires est la première étape de l'intégration continue pour garantir l'exécution et la conformité du code vis-à-vis des attentes du client.

De nombreux langages comprennent des frameworks de tests unitaires type xUnit qui ont tous un cœur semblable si ce n'est commun. On peut citer par exemple : JUnit, CppUnit, VbUnit, NUnit, NUnitHttp, .

Tout outil indispensable de la communauté .NET est « destiné » - à plus ou moins court terme - à être intégré à Visual Studio et NUnit n'a pas échappé à la règle. On retrouve en effet depuis Visual Studio 2005 (namespace Microsoft.VisualStudio.QualityTools) un framework très similaire à celui que propose NUnit pour l'écriture de tests unitaires. C'est l'utilitaire MsTest qui permet l'exécution de ces tests. (7)

Il est bien sûr tout à fait possible de continuer à utiliser NUnit pour l'écriture de tests unitaires, mais cela requerra un peu plus de travail si nous voulons automatiser ces tests dans notre build.

Notez que cet outil est installé par défaut dans le répertoire « %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE » pour Visual Studio 2005 et « %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE » pour Visual Studio 2008.

Dès la version 1.0 du framework .NET, la communauté Microsoft a mis à disposition des développeurs l'outil FxCop. Il est maintenant intégré dans Visual Studio 2005.

Cet outil (renommé « Static Code Analysis ») permet de faire une analyse statique du code autrement dit une analyse lors de la compilation et non lors de l'exécution.

Il permet de vérifier qu'un certain nombre de règles (paramétrables) ont bien été respectées. On peut citer - entre autres - des règles liées au respect :

• des conventions de nommage (une classe héritant de System.Exception doit être suffixée par Exception) ;
• des principes de design (un événement doit avoir une signature acceptant deux paramètres : un System.Object et une classe héritant de System.EventArgs) ;
• des performances (utiliser const plutôt que shared readonly) ;
• de sécurité (un constructeur statique doit être privé).

Vous pouvez soit lancer une analyse à la demande (clic droit sur un projet et « Run Code Analysis »), soit la lancer à chaque compilation en activant l'analyse statique dans les propriétés du projet (Clic droit sur un projet et Properties / Code Analysis / Enable Code Analysis).

MsBuild est la pierre angulaire de l'intégration continue dans le monde Microsoft : c'est l'outil qui permet l'automatisation de tâches diverses (compilation, déploiement d'une solution, exécution de tests…).

La communauté Microsoft avait déjà fourni des outils d'intégration continue - pour la plupart des portages du monde Java - comme CruiseControl.NET et NAnt. Mais c'est à partir de la version 2005 que Microsoft inclut son propre moteur au sein de Visual Studio.

Il est même utilisé en interne pour la compilation des solutions et des projets. Il est donc beaucoup plus « simple » (ou tout du moins envisageable sans refaire tout le processus en ligne de commande) de paramétrer la compilation de nos projets dans Visual Studio en modifiant le fichier de build utilisé par Visual Studio. (8)

MsBuild permet en fait d'exécuter un fichier de projet (ou fichier de build), traditionnellement d'extension « .proj » ou « .target ». (9) Il s'agit en fait d'un fichier XML représentant une série d'actions.

Ce fichier de projet génèrera une fois exécuté un fichier texte comportant tous les messages, avertissements ou erreurs relatifs à l'exécution.

L'outil MsBuild est installé avec le framework, autrement dit dans le répertoire « %Windir%\Microsoft.NET\Framework\VersionFramework », soit typiquement dans les répertoires :

• « %Windir%\Microsoft.NET\Framework\v2.0.50727 » pour .NET 2.0 ;
• « %Windir%\Microsoft.NET\Framework\v3.5 » pour .NET 3.5.

TFSBuild est une surcouche au-dessus de MsBuild pour réaliser plus facilement de l'intégration continue avec le Team Foundation Server, en permettant de simplifier la création de builds. Il va typiquement exécuter des actions comme :

• récupération des sources à partir du Source Control ;
• compilation des sources ;
• exécution des tests ;
• publication des résultats sur le Team Foundation Server.

Le build sera alors typiquement considéré comme réussi si :

• la compilation des sources a réussi ;
• tous les BVTs sont passés avec succès.

Le processus de build est cependant entièrement paramétrable et il peut donc échouer pour bien d'autres raisons. Nous verrons dans une autre partie comment le paramétrer.