V. Tests unitaires : Exécuter des tests avec MsTest▲
V-A. Exécution via Visual Studio▲
Dans toutes les versions, Visual Studio nous propose les onglets « Test View » et « Test List Editor ». (14)
On peut l'activer via le menu « Test / Window / Test View ». Il suffit alors de sélectionner un test et de choisir « clic droit / Run » ou « clic droit / Debug ».
Notez que Visual Studio 2008 propose aussi plusieurs touches de raccourci pour lancer les tests :
Run |
Debug |
Signification |
---|---|---|
Ctrl + R, A |
Ctrl + R, Ctrl + A |
Tous les tests |
Ctrl + R, D |
Ctrl + R, Ctrl + D |
Tous les tests du dernier « test run » |
Ctrl + R, F |
Ctrl + R, Ctrl + F |
Tous les tests cochés dans le dernier « test run » (donc par défaut, tous les tests échoués du dernier « run ») |
Ctrl + R, T |
Ctrl + R, Ctrl + T |
Tous les tests du contexte courant(TestMethod, TestClass, Namespace, projet, tout dépendant de la position du curseur) |
Ctrl + R, C |
Ctrl + R, Ctrl + C |
Tous les tests de la TestClass courante |
Ctrl + R, N |
Ctrl + R, Ctrl + N |
Tous les tests du Namespace courant |
Nous détaillerons ci-après l'utilisation des vues « Test View » et « Test List Editor ».
V-B. Exécution en ligne de commande▲
On peut également choisir d'exécuter MsTest en ligne de commande. Il est pour cela préférable de définir le chemin d'accès à MsTest dans la variable d'environnement %Path%.
On pourra ainsi lancer les tests à partir du répertoire de la DLL de test ce qui nous évitera de trop longues commandes.
Vous trouverez ci-dessous plusieurs exemples pour exécuter MsTest.
V-B-1. Exécution d'une liste de test▲
Lors de l'ajout de tests dans un projet, un fichier « .vsmdi » est aussitôt ajouté. C'est lui qui stocke les différentes listes de tests du projet. Si l'on désire lancer une liste de test particulière (voir ci-après pour la création d'une liste de test), on peut alors utiliser la commande suivante :
Mstest /testmetadata:testList1.vsmdi /testlist:iteration3.3
V-B-2. Exécution de tous les tests d'une DLL▲
Si l'on ne travaille pas avec une liste de test, il est possible de lancer tous les tests (c'est-à-dire toutes les TestMethod des TestClass d'une DLL). Pour cela, on utilise le switch « testcontainer ».
Mstest /testcontainer:maDllDeTest.dll
Notez que « testcontainer » peut être précisé plusieurs fois, si on veut lancer les tests de plusieurs DLL différentes.
V-B-3. Exécution de certains tests d'une DLL▲
Si on veut filtrer les tests que l'on veut exécuter, alors on peut utiliser le switch « test ».
Mstest /testcontainer:maDllDeTest.dll /test:NomTest
Notez que dans ce cas, « NomTest » peut être le nom de la TestClass ou de la TestMethod.
Cependant « NomTest » ne doit pas forcément être le nom exact. En effet, si vous précisez « Test », tous les tests (TestClass ou TestMethod) s'appelant « *Test* » seront lancés, soit par exemple les tests « CeciEstUnTest » et « TestSurLesEntiers ».
V-B-4. Configuration supplémentaire▲
On peut également spécifier un fichier de configuration à utiliser. Se reporter à la section Configuration des tests pour plus d'informations sur les fichiers de configuration.
Mstest /testcontainer:maDllDeTest.dll /test:NomTest
/runconfig:mytestrunconfig.testrunconfig
On peut également spécifier l'emplacement du fichier de résultat d'exécution des tests. Il s'agit d'un fichier d'extension « .trx » qui pourra être ouvert dans Visual Studio.
Mstest /testcontainer:maDllDeTest.dll /test:NomTest
/runconfig:mytestrunconfig.testrunconfig
/resultsfile:c:\temp\results.trx
Il est à noter cependant que toute exécution de test produira un fichier de résultat « .trx », que celui-ci soit fixé dans la ligne de commande ou non. Ce fichier - qui sera généré par défaut dans un répertoire « TestResults » situé dans le répertoire d'exécution - peut être importé dans Visual Studio afin d'avoir plus d'informations sur les erreurs survenues, soit en passant par le menu « File / Open / File », soit en passant par la fenêtre « Test Results » et par la commande « Import Test Results ».
Notez également que MsTest utilise un code de retour signifiant :
- 0 : tous les tests exécutés ont réussi ;
-
1 : au moins un test a échoué, ce qui signifie :
- une exception a été levée dans le corps du test (et non « catchée » par l'attribut ExpectedException),
- le test est parti en timeout,
- le test a échoué (Assert.Fail ou un autre Assert a échoué),
- le test a lancé un Assert.Inconclusive,
- le test a réussi, mais l'exécution des tests a été stoppée.