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

Imaginons que l'on ait une classe internal dans notre projet et que l'on veuille la tester. On peut alors utiliser l'attribut InternalsVisibleToAttribute.

Cet attribut se spécifie au niveau de l'assembly contenant le code à tester (typiquement dans le fichier AssemblyInfo) et permet à une autre assembly (celle contenant le code de test) de voir tous les membres internal comme s’ils étaient publics.

En supposant la solution suivante (Test.MyConsoleApplication référençant MyConsoleApplication) :

On peut déclarer la classe interne suivante :

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("Test.MyConsoleApplication")]
namespace MyConsoleApplication
{
   internal class MaClasseInterne
   {
      internal void MaMethodeInterne()
      { }
   }
}

Et on peut alors la tester de la façon suivante, comme si la classe était publique :

using Microsoft.VisualStudio.TestTools.UnitTesting;
using MyConsoleApplication;

namespace Test.MyConsoleApplication
{
   [TestClass]
   public class MaClasseInterneTest
   {
      [TestMethod]
      public void MaMethodeTest()
      {
         MaClasseInterne maClasse = new MaClasseInterne();
         maClasse.MaMethodeInterne();
         //Autre code de test omis
      }
   }
}

Si jamais on a une DLL signée (i.e. avec un strong name), nous allons également devoir signer notre DLL de test, puis spécifier sa clé publique lors de la déclaration de l'attribut.

Nous allons tout d'abord utiliser l'outil « sn » pour extraire la clé publique de notre DLL / exe. Cet outil est installé avec Visual Studio et peut être trouvé dans le répertoire « %ProgramFiles% \ Microsoft Visual Studio 8 \ SDK \ v2.0 \ Bin ». (13)

La syntaxe est la suivante :

Sn -Tp « Dll Path »

Dans mon cas, l'exécution de la ligne de commande donne le résultat suivant :

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>sn -Tp 
   "c:\Projects\MyTestSolution\Test.MyConsoleApplication\bin\Debug\
   Test.MyConsoleApplication.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key is
00240000048000009400000006020000002400005253413100040000010001007b9e3798f117b7
8553f96e3c9bfae4fe533e1ad47dea71ea486b9f70a473570466d006cadce035730a1c96470e73
fad75c61cb90492825ba903c7b5aceafd2df8e57ab202b03687f7277e045c2d9b8085a446bbba6
c9c807617bf88052aab98c31fb6674afee59f9df5ce01cbe77c079c6eacc53287e6c26fd6b809b
df9ffce4

Public key token is ccc3404edeae0195

On pourra alors mettre à jour l'attribut pour introduire la clé publique.

[assembly: InternalsVisibleTo("Test.MyConsoleApplication, 
                               PublicKey=0024000004......809bdf9ffce4")]

De même, et pour les mêmes raisons, il peut être très intéressant de tester des méthodes non private ou protected.

Dès la version 2005 de Visual Studio, Microsoft a mis à notre disposition les « accesseurs » : il s'agit en fait de classes générées permettant d'atteindre (via réflexion) le code non public.

Cette fonctionnalité a fortement évolué depuis 2005 :

Imaginons maintenant que je rajoute un fichier dans mon projet avec la définition de certaines classes ou membres privates.

Pour générer un accesseur, il suffit :

• d'ouvrir un des fichiers du projet pour lequel on veut générer un accesseur ;
• clic droit sur le code et choisir « Create Private Accessor », puis de choisir le nom de la DLL de test vers laquelle on veut générer l'accesseur ;
• nous avons maintenant un accesseur dans notre projet de test.

Si nous avons écrit le code suivant :

namespace MyConsoleApplication
{
   public class MaClassePossedantDesMembresPrivate
   {
      private void MaMethodePrivee() { }

      private static void MaMethodeStatique() { }
   }

   public class ClasseAvecConstructeurPrivate
   {
      private ClasseAvecConstructeurPrivate(int i) { }
   }
}

Nous pouvons commencer par écrire un test pour appeler les membres de la classe MaClassePossedantDesMembresPrivate.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using MyConsoleApplication;

namespace Test.MyConsoleApplication
{
   [TestClass]
   public class MaClassePossedantDesMembresPrivateTest
   {
      [TestMethod]
      public void MonTest()
      {
         MaClassePossedantDesMembresPrivate maClasse 
            = new MaClassePossedantDesMembresPrivate();

         //1. Créer un accesseur pour appeler un membre d'instance
         MaClassePossedantDesMembresPrivate_Accessor accessor 
            = MaClassePossedantDesMembresPrivate_Accessor.AttachShadow(maClasse);
         accessor.MaMethodePrivee();

         //2. Utiliser l'accesseur pour appeler un membre static
         MaClassePossedantDesMembresPrivate_Accessor.MaMethodeStatique();
      }
   }
}

Ici on veut tester une classe instanciable. On peut donc créer une instance en utilisant le constructeur standard, et on utilise alors la méthode AttachShadow pour créer un accesseur qui nous permet d'accéder à l'instance qu'on lui fournit.

Toutes les méthodes non publiques sont alors disponibles sur cette instance d'accesseur.

En ce qui concerne les membres statiques, ils sont simplement disponibles sur le type de l'accesseur même.

Notez que la DLL de l'accesseur suit fidèlement la structure de la DLL originale, et que l'on retrouve exactement les mêmes namespace.

Si l'on veut tester un type en utilisant son constructeur privé, nous pouvons alors simplement utiliser le constructeur de l'accesseur comme suit :

using Microsoft.VisualStudio.TestTools.UnitTesting;
using MyConsoleApplication;

namespace Test.MyConsoleApplication
{
   [TestClass]
   public class ClasseAvecConstructeurPrivateTest
   {
      [TestMethod]
      public void MonTest_CtorPrivee()
      { 
         //On utilise le constructeur de l'accesseur pour utiliser un constructeur privé
         ClasseAvecConstructeurPrivate_Accessor accessor 
            = new ClasseAvecConstructeurPrivate_Accessor(100);

         //Utilisation de la propriété Target pour accéder à l'instance
         ClasseAvecConstructeurPrivate instance 
            = accessor.Target as ClasseAvecConstructeurPrivate;
      }
   }
}

Comme nous l'avons vu, Visual Studio nous permet de créer facilement une DLL d'accesseurs. Cependant, ceci n'est possible que dans une DLL de test.

Supposons le scénario suivant : vous avez plusieurs DLL de tests, qui contiennent du comportement commun que vous voulez centraliser. Vous allez donc créer une « Class Library » qui va contenir ce comportement commun.

Cependant vous allez avoir besoin de travailler avec certaines classes d'accesseurs.

Dans ce cas, Visual Studio ne vous permet pas de créer un accesseur via l'interface graphique, car votre DLL cible est une « Class Library » et non une DLL de test. Il est cependant possible de le faire en travaillant directement dans votre fichier de projet « .csproj » ou « .vbproj ».

• Ajoutez un nouveau répertoire dans votre projet et nommez-le « Test References ».
• Ajoutez un fichier texte dans ce répertoire et nommez le « MonNomDeProject.accessor » où MonNomDeProjet est le nom du projet pour lequel vous voulez créer un accesseur.

• Éditez ce fichier pour y ajouter deux lignes :

  • sur la première ligne : le nom de la DLL/exe pour laquelle vous voulez créer un accesseur, extension comprise (par exemple : MonProjet.dll) ;
  • sur la deuxième ligne : « Desktop ».
• Cliquez droit sur votre projet et choisissez « Unload Project ».
• Cliquez droit sur votre projet et choisissez « Edit xxx.csproj ».
• Ajoutez un nouvel ItemGroup avec les informations de l'accesseur (voir ci-dessous). Notez que cet ItemGroup doit se situer au même niveau que les autres éléments ItemGroup.

MyConsoleApplication.exe
Desktop

<ItemGroup>
  <Shadow Include="Test References\MyConsoleApplication.accessor" />
</ItemGroup>

Vous pouvez alors recharger votre projet, et vous pourrez alors accéder à votre accesseur comme si vous étiez dans votre DLL de test.