Das Beste aus TAEF

Das Testerstellungs- und Ausführungsframework bietet Ihnen eine leistungsstarke Plattform zum Erstellen und Ausführen Ihrer Tests. Es kann von Vorteil sein, einige hinter den Kulissen funktionierende Details von TAEF zu verstehen, um das Beste daraus zu machen. Auf dieser Seite werden einige Tipps und Features erläutert, mit denen Sie Ihre Tests erstellen können, um das, was TAEF zu bieten hat, zu optimieren und optimal zu nutzen. Stellen Sie sicher, dass Sie mit den Grundlagen der Erstellungs- und Ausführungstests mit TAEF vertraut sind.

Einrichten (oder Initialisieren) und Bereinigen von Methoden

Die Setup- und Bereinigungsmethoden auf Assemblyebene (auch als Fixierungen bezeichnet) werden einmal pro DLL-Ausführung ausgeführt. Ebenso werden die Setup- und Bereinigungsmethoden auf Klassenebene einmal pro Klasse ausgeführt. Die Setup- und Bereinigungsmethoden auf Testebene sind für alle Tests innerhalb einer Klasse identisch und werden einmal vor und nach jedem Test in der Klasse aufgerufen.

Es kann nur eine Setup- und Bereinigungsmethode auf Assemblyebene pro Assembly, eine Einrichtungs- und Bereinigungsmethode auf Klassenebene pro Klasse und eine Testeinrichtungs- und Bereinigungsmethode pro Klasse geben. Beachten Sie, dass Klassensetup- und Bereinigungsmethoden in verwaltetem Code statisch, aber in C++-Code nicht statisch sind.

Wenn Ausnahmen aktiviert sind (Standardfall), wird die Ausführung einer beliebigen Methode beim ersten Verify-Aufruf beendet, bei dem ein Fehler auftritt. Wenn Sie ausnahmebasierte Überprüfungsaufrufe explizit deaktiviert haben (weitere Informationen finden Sie im Abschnitt Überprüfen unter Erstellungstests), müssen Sie explizite bedingte Anweisungen verwenden, um den Ablauf der Steuerung zu steuern, nachdem ein Verify-Aufruf fehlschlägt.

Für den Fall, dass der Fehler in einer Setupmethode auftritt (entweder durch ausnahmebasierte Überprüfungsfehler oder durch explizite Rückgabe eines Fehlers), werden die folgenden Tests als "Blockiert" betrachtet und als solche protokolliert. Wenn die Setupmethode auf Klassenebene beispielsweise fehlschlägt, werden alle Testmethoden in der Klasse als "Blockiert" betrachtet, und jede von ihnen wird als solche protokolliert. Darüber hinaus wird die Cleanup-Methode nicht aufgerufen, wenn der Fehler in einer Setupmethode auftritt.

Testmethode

Es ist nicht erforderlich, das Testergebnis explizit zu protokollieren. Wenn alle Verify-Aufrufe in Ihrem Test erfolgreich waren, wird der Test als "Bestanden" protokolliert. Beim ersten Verify-Aufruf, der fehlschlägt, wird die Ausführung der Testmethode beendet (es sei denn, Sie haben ausnahmebasierte Verify-Aufrufe explizit deaktiviert – in diesem Fall bestimmen Ihre bedingten Anweisungen den Ablauf dort nach, aber unabhängig von den folgenden Haltebereichen), und der Test wird als "Fehler" gekennzeichnet.

Wenn Sie über einen VERIFY-Wrapper (abhängig vom Rückgabetyp und dem, was den Erfolg bestimmt) um einen Aufruf der Hilfsmethode verfügen, müssen Sie das Ergebnis nicht explizit überprüfen und protokollieren.

Angeben von Metadaten

Die Metadatensuche ist hierarchisch. Dies bedeutet, wenn Ihre select-Anweisung /select:"@Priority=2" lautet und Ihre TestMethod keine Priorität angibt, sucht TAEF nach der Klasse, die sie enthält. Wenn die Metadaten auf Klassenebene dies nicht angeben, sucht TAEF auf Assemblyebene nach.

Wenn Sie also möchten, dass alle oder die meisten Tests in Ihrer Klasse die gleiche "Priorität" haben oder "Besitzer" sagen, können Sie dies erreichen, indem Sie sie einfach auf Klassenebene angeben. Für den einen oder wenige Tests, die eine Ausnahme von dieser Regel darstellen, können Sie die Metadaten explizit auf der Ebene "TestMethod" angeben. Weitere Informationen finden Sie im folgenden Test:

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 */

HINWEIS: Bei verwalteten Tests erfolgt die Erstellung auf ähnliche Weise. Die Modulebene entspricht dem Markup auf Assemblyebene in managed. Für metadatenspezifikation auf Assemblyebene oder Klassenebene in verwaltetem Code muss das Markup vor den statischen Initialisiermethoden bereitgestellt werden. Dies kann bedeuten, dass Sie möglicherweise einen leeren Initialisierer bereitstellen müssen, wenn Ihr Test noch keinen hat. Dieser Entwurf wurde speziell entwickelt, um die VSTS-Kompatibilität sicherzustellen.

Bei tabellenbasierten datengesteuerten Tests können Sie dies einen Schritt weitergehen und Metadaten auf Testebene überschreiben, indem Sie sie auf Zeilenebene angeben. Weitere Informationen finden Sie unter Beispiel für das Außerkraftsetzungen von datengesteuerten Tests .