Silverlight – Multiples projets de tests unitaires

Warning : This page has been marked as an archive because the author consider that its content is no longer relevant.

Introduction

Les projets de tests unitaires en Silverlight tels qu’ils existent dans le Silverlight Toolkit sont des applications s’exécutant de manière autonome.

Lorsque l’on teste un projet Silverlight seul, ça ne pose généralement pas de problèmes :

Notre application de test (ici TestMyApp.Tests) fait référence à notre application Silverlight à tester (TestMyApp). On n’a donc alors plus qu’à exécuter le projet de tests pour tester l’application.

Prenons maintenant l’exemple d’une application Silverlight composée de plusieurs projets :

Dans ce cas, deux possibilités : soit on garde un seul projet de test qui référencera tous les projets Silverlight et les testera (ce que je vous déconseille de faire), soit on crée un projet de test par projet Silverlight à tester.

L’inconvénient, c’est qu’on doit lancer chaque projet de tests manuellement.

Le but de cet article va donc être de montrer comment on peut exécuter tous les tests via le projet TestMyApp.Tests.

Un prérequis cependant, nous devrons nommer tous nos projets de tests avec la forme *.Tests. Cette convention permet de faire la différence entre les projets contenant des tests unitaires et les autres.

Décomposition d’une application de test

Une application de tests unitaires Silverlight est avant tout une application Silverlight. La principale différence entre une application Silverlight classique et une application de test se situe dans le gestionnaire de l’évènement Startup :

private void Application_Startup(object sender, StartupEventArgs e)
{
    RootVisual = UnitTestSystem.CreateTestPage();
}

On peut voir ci-dessus que l’on affecte à la propriété RootVisual de notre application une page de projet de test. Le framework de test fait de la reflection sur l’assembly courant afin de trouver et d’exécuter les tests unitaires et génère une page qui ressemble à celle-ci :

Afin de pouvoir exécuter plusieurs tests, nous allons modifier l’évènement startup.

Modification de l’initialisation de l’application

Dans un premier temps il faut choisir l’application de test principale. Ici, on va choisir l’application TestMyApp.Tests. Dans cette application, il faut référencer les autres applications de tests.

Une fois les références correctement ajoutées, on peut modifier le gestionnaire de l’évènement startup.

private void Application_Startup(object sender, StartupEventArgs e)
{
    UnitTestSettings settings = UnitTestSystem.CreateDefaultSettings();

    var testAssemblies = Deployment.Current.Parts.Where(p => p.Source.EndsWith(".Tests.dll")).ToList();
    foreach (AssemblyPart part in testAssemblies)
    {
        Uri assemblyUri = new Uri(part.Source, UriKind.Relative);
        Stream ressourceStream = GetResourceStream(assemblyUri).Stream;
        AssemblyPart assemblyPart = new AssemblyPart();

        Assembly assembly = assemblyPart.Load(ressourceStream);

        settings.TestAssemblies.Add(assembly);
    }

    RootVisual = UnitTestSystem.CreateTestPage(settings);
}

Le code ci-dessus permet d’ajouter au projet de test principal la liste des assembly dont le nom se termine par .Tests.dll. Problème de ceci : notre assembly courant répond aussi à ce critère et dans les propriétés par défaut d’un projet de test, l’assembly courant est déjà chargé. Conséquence : le projet sera chargé deux fois. Pour éviter ça, on va donc améliorer la requête Linq de la manière suivante :

var currentAssembly = GetCurrentAssemblyName();
var testAssemblies = Deployment.Current.Parts.Where(p => p.Source != currentAssembly && p.Source.EndsWith(".Tests.dll")).ToList();

La méthode GetCurrentAssemblyName est définie de cette façon :

private static string GetCurrentAssemblyName()
{
    string currentAssembly = Assembly.GetExecutingAssembly().FullName;
    currentAssembly = currentAssembly.Substring(0, currentAssembly.IndexOf(','));
    return currentAssembly + ".dll";
}

Lancement de l’application

Notre projet de test est maintenant prêt et si on l’exécute, voilà ce qu’on obtient :

Maintenant vous n’avez plus aucune excuses pour ne pas tester vos applications Silverlight.

C’est tout pour aujourd’hui !