Tirer le meilleur parti de TAEF

L’infrastructure de création et d’exécution des tests vous offre une plateforme puissante pour créer et exécuter vos tests. Il peut être utile de comprendre certains détails du fonctionnement en arrière-plan de TAEF afin d’en tirer le meilleur parti. Cette page présente quelques conseils et fonctionnalités qui vous aideront à créer vos tests pour optimiser et tirer le meilleur parti de ce que TAEF a à offrir. Assurez-vous que vous êtes familiarisé avec les principes de base de la création et de l’exécution de tests avec TAEF.

Configurer (ou initialiser) et nettoyer des méthodes

Les méthodes d’installation et de nettoyage au niveau de l’assembly (également appelées « fixtures »), sont exécutées une fois par exécution de DLL. De même, les méthodes d’installation et de nettoyage au niveau de la classe sont exécutées une fois par classe. Les méthodes de configuration et de nettoyage au niveau du test sont les mêmes pour tous les tests au sein d’une classe et sont appelées une fois avant et après chaque test de la classe .

Il ne peut y avoir qu’une seule méthode de configuration et de nettoyage au niveau de l’assembly par assembly, une méthode de configuration et de nettoyage au niveau de la classe par classe et une méthode de configuration et de nettoyage de test par classe. Notez que les méthodes de configuration et de nettoyage de classe sont statiques dans le code managé, mais ne sont pas statiques dans le code C++.

Si les exceptions sont activées (cas par défaut), l’exécution d’une méthode est arrêtée lors du premier appel Verify qui échoue. Si vous avez explicitement désactivé les appels de vérification basés sur les exceptions (voir la section Vérifier dans La création de tests pour plus d’informations), vous devez disposer d’instructions conditionnelles explicites pour régir le flux de contrôle après l’échec d’un appel Verify.

Dans le cas où l’échec se produit dans une méthode d’installation (par le biais d’un échec de vérification basée sur l’exception ou par l’installation retournant explicitement un échec), les tests qui devaient suivre sont considérés comme « bloqués » et consignés comme tels. Par exemple, si votre méthode d’installation au niveau de la classe échoue, toutes les méthodes de test de la classe sont considérées comme « bloquées » et chacune d’elles est journalisée en tant que telle. En outre, la méthode Cleanup ne sera pas appelée si l’échec se produit dans une méthode Setup.

Méthode de test

Il n’est pas nécessaire de consigner explicitement le résultat du test. Si tous les appels De vérification de votre test ont réussi, le test est enregistré comme « Réussi ». Lors du premier appel Verify qui échoue, l’exécution de la méthode de test s’arrête (sauf si vous avez explicitement désactivé les appels de vérification basés sur les exceptions ; dans ce cas, vos instructions conditionnelles déterminent le flux de contrôle après, mais quelles que soient les conservations suivantes) et le test est marqué comme « Échec ».

De même, si vous avez un wrapper VERIFY (dépend du type de retour et de ce qui détermine la réussite) autour d’un appel de méthode d’assistance, vous n’avez pas besoin de case activée explicitement et de journaliser son résultat.

Spécification des métadonnées

La recherche de métadonnées est hiérarchique. Cela signifie que si votre instruction select est /select:"@Priority=2 », et si votre TestMethod ne spécifie pas Priority, TAEF recherchera la classe qui la contient. Si les métadonnées au niveau de la classe ne le spécifient pas, TAEF recherche au niveau de l’assembly.

Par conséquent, si vous souhaitez que la totalité ou la plupart des tests de votre classe aient la même « Priorité », ou dites « Propriétaire , vous pouvez l’obtenir en le spécifiant simplement au niveau de la classe. Pour les tests qui constituent une exception à cette règle, vous pouvez fournir explicitement les métadonnées au niveau « TestMethod ». Pour plus d’informations, consultez le test suivant :

1    namespace WEX { namespace UnitTests { namespace Samples
2    {
3        //
4        // Declare module level properties
5        //
6        BEGIN_MODULE() //This metadata applies to all the classes and tests in this module or assembly
7            MODULE_PROPERTY(L"GroupOwner", L"SomeGroup")
8        END_MODULE()
9        class PremiumBankAccountTests
10       {
11           //
12           // Declare this class to be a test class with an'advanced' declaration
13           // Use advanced declaration when you want to set metadata on the class
14           //
15           BEGIN_TEST_CLASS(PremiumBankAccountTests) //This metadata applies to all the test in this class
16               TEST_CLASS_PROPERTY(L"Priority", L"2")
17               TEST_CLASS_PROPERTY(L"DevOwner", L"Someone")
18               TEST_CLASS_PROPERTY(L"PMOwner", L"Someone")
19           END_TEST_CLASS()
20           //
21           // Declare class setup - a method that runs after class constructor
22           // and before any test class methods and test setup method
23           //
24           TEST_CLASS_SETUP(SetDefaultAccountType);
25           //
26           // Declare class cleanup - a methods that runs after all the class test methods and test setup method
27           // and before the class destructor
28           //
29           TEST_CLASS_CLEANUP(ResetDefaultAccountType);
30           //
31           // Declare test setup and cleanup - methods that run before and after the execution
32           // of every test method correspondingly
33           //
34           TEST_METHOD_SETUP(CreateBankAccount);
35           TEST_METHOD_CLEANUP(DestroyBankAccount);
36           //
37           // Declare test methods with an 'advanced' declaration
38           // Use advanced declaration when you want to set metadata on the methods
39           //
40           BEGIN_TEST_METHOD(DebitTest)
41               TEST_METHOD_PROPERTY(L"BVT", L"TRUE")
42               TEST_METHOD_PROPERTY(L"PERF", L"TRUE")
43               TEST_METHOD_PROPERTY(L"STRESS", L"FALSE")
44               TEST_METHOD_PROPERTY(L"Priority", L"1") //Overrides the Class level Priority value
45           END_TEST_METHOD()
46           BEGIN_TEST_METHOD(CreditTest)
47               TEST_METHOD_PROPERTY(L"BVT", L"TRUE")
48               TEST_METHOD_PROPERTY(L"PERF", L"FALSE")
49               TEST_METHOD_PROPERTY(L"STRESS", L"TRUE")
50               TEST_METHOD_PROPERTY(L"GroupOwner", L"SomeGroupTest") //Overrides the GroupOwner specified at the Module level
51           END_TEST_METHOD()
52   
53           std::unique_ptr<BankAccount> m_spBankAccount;
54           BankAccountType m_defaultType;
55       };
56   } /* namespace Samples */ } /* namespace UnitTests */ } /* namespace WEX */

REMARQUE : Pour les tests managés, la création est effectuée de la même façon. Le niveau du module est identique au balisage au niveau de l’assembly dans managé. Pour la spécification de métadonnées au niveau de l’assembly ou de la classe dans le code managé, le balisage doit être fourni avant les méthodes d’initialiseur statiques. Cela peut signifier que vous devrez peut-être fournir un initialiseur vide si votre test n’en a pas déjà un. Cette conception est spécifiquement conçue pour garantir la compatibilité VSTS.

Dans le cas de tests basés sur des données basés sur des tables, vous pouvez aller plus loin et remplacer les métadonnées de niveau de test en les spécifiant au niveau de la ligne. Pour plus d’informations, consultez Exemple de test piloté par les métadonnées de substitution des données .