Rédaction de tests en C#
L’exemple ci-dessous montre un fichier .cs C# avec une classe de test unique simple qui illustre le balisage des tests C#. (Il convient de noter que cet exemple est uniquement fourni à des fins de démonstration. Il ne sera donc ni compilé ni exécuté.)
1 using Microsoft.VisualStudio.TestTools.UnitTesting;
2 using System;
3 using System.Collections;
4 using WEX.Logging.Interop;
5 using WEX.TestExecution;
6
7 [TestClass]
8 public class ManagedStartMenuTests
9 {
10 [AssemblyInitialize]
11 [TestProperty("Component", "Navigation")]
12 [TestProperty("SubComponent", "StartMenu")]
13 public static void RunModuleSetup(Object context)
14 {
15 defaultPolicy = SetObjectFactoryPolicy(PolicyClassic);
16 }
17
18 [AssemblyCleanup]
19 public static void RunModuleCleanup()
20 {
21 SetObjectFactoryPolicy(defaultPolicy);
22 }
23
24 [ClassInitialize]
25 [TestProperty("TeamOwner", "WEX")]
26 [TestProperty("GroupOwner", "MediaPlayerTest")]
27 public static void TestClassSetup(Object testContext)
28 {
29 objectFactory = new ObjectFactory();
30 }
31
32 [ClassCleanup]
33 public static void TestClassCleanup()
34 {
35 objectFactory.Dispose();
36 }
37
38 [TestInitialize]
39 public void TestMethodSetup()
40 {
41 startMenuObject = objectFactory.CreateObject();
42 }
43
44 [TestCleanup]
45 public void TestMethodCleanup()
46 {
47 startMenuObject.Dispose();
48 }
49
50
51 [TestMethod]
52 [Owner("Someone")]
53 [Priority(0)]
54 public void TestMethod1()
55 {
56 Verify.AreEqual(startMenuObject.size, expectedObjectSize);
57 }
58 }
Pour déclarer des tests c#, TAEF utilise le balisage de test VSTS.
Pour déclarer une classe de test en C#, utilisez l’attribut [TestClass] sur une classe C# ordinaire (ligne 7) et pour une déclaration de méthode de test, utilisez l’attribut [TestMethod] sur une méthode de classe ordinaire (ligne 51).
Le balisage des tests C# prend également en charge une gamme complète de méthodes de configuration et de nettoyage.
La méthode statique avec le jeu d’attributs [AssemblyInitialize] s’exécute avant toute autre méthode de classe et effectue l’initialisation au niveau de l’assembly (ligne 10). Par conséquent, il existe une méthode de nettoyage de l’assembly, une méthode statique avec le jeu d’attributs [AssemblyCleanup] qui s’exécute une fois toutes les autres méthodes terminées (ligne 18).
De même, il existe des méthodes de configuration et de nettoyage des classes et des tests (voir les lignes 24, 32, 38, 44). Contrairement à ce qui se passe en C++, les méthodes de configuration et de nettoyage des classes dans le code géré doivent être statiques.
Le balisage des tests TAEF C# prend en charge les propriétés des tests, des classes et des modules.
Pour définir les propriétés du module, définissez des attributs sur un initialiseur d’assembly (voir lignes 11 et 12). De même, pour définir les propriétés au niveau de la classe, définissez les propriétés d’un initialisateur de classe (voir lignes 25 et 26). Pour une propriété au niveau d’une méthode de test, il suffit d’appliquer la propriété à une méthode de test particulière (voir lignes 52 et 53).
Exécution sous VSTS
Remarque : pour réduire la dépendance des fichiers binaires de VSTS, les méthodes de configuration de Classe et d’Assembly prennent Object comme premier paramètre.
Si vous souhaitez exécuter les tests à partir de VSTS, modifiez ce type d’objet en type TestContext. N’oubliez pas que cela ajoutera une dépendance à microsoft.visualstudio.qualitytools.unittestframework.dll et microsoft.visualstudio.qualitytools.resource.dll.
Les étapes sont un peu différentes lors de l’exécution sous VSTS. Vous devez configurer vos paramètres d’exécution de test local pour copier vos dépendances non gérées. Pour ce faire, accédez à :
- Test->Modifier les configurations d’exécution de tests->Exécuter un test local
- Cliquez sur Deployment. Saisissez les dll que vous avez copiées pour chaque test :
- Wex.Logger.dll
- Wex.Common.dll
- Wex.Common.Managed.dll
- Wex.Communication.dll
- Wex.Logger.Interop.dll
Cela est nécessaire parce que VSTS crée un nouveau répertoire et copie des fichiers chaque fois qu’il exécute vos cas de test. Vous pouvez voir ces répertoires sur votre ordinateur en tant que dossier frère dans votre dossier de projet.
Exécution de tests gérés dans le domaine d’application par défaut
Pour isoler le code de test, TAEF exécute par défaut les tests gérés dans un domaine d’application de test spécial. Cependant, lors de l’utilisation de domaines d’application autres que ceux par défaut, les scénarios dans lesquels le code natif fait appel au code géré (par exemple, les fonctions de rappel natives consommées par le code géré) peuvent provoquer des erreurs avec le message : « Impossible de transmettre un GCHandle entre AppDomains ». Pour ces scénarios, forcez les tests gérés à s’exécuter dans le domaine d’application par défaut à l’aide du commutateur /defaultAppDomain.
Il convient de noter que l’exécution de tests gérés dans le domaine d’application par défaut n’est pas compatible avec des fichiers de configuration d’assembly.
Prise en charge de méthodes de test asynchrones
Les binaires NetFX 4.5 de TAEF prennent en charge l’exécution des méthodes de test TAEF asynchrones. Cela signifie que les tests TAEF marqués avec le mot clé async sont en mesure d’attendre des opérations asynchrones.
Remarque : n’essayez pas d’exploiter cette fonctionnalité avec les binaires NetFX 2.0/3.5 de TAEF. Seuls les binaires NetFX 4.5 prennent en charge cette fonctionnalité.
TAEF prend en charge les méthodes de test void et async Task (les deux ont la même fonctionnalité) :
[TestMethod]
public async Task MyAsyncTest()
{
await AsyncAPICall1();
var result = await AsyncAPICall2();
Verify.IsTrue(result);
}
Sinon :
[TestMethod]
public async void MyAsyncTest2()
{
await AsyncAPICall1();
var result = await AsyncAPICall2();
Verify.IsTrue(result);
}