VS-Team-Test: Mehrere Test-Initialisierungsmethoden in der Testklasse

Nach MSDN das TestInitializeAttribute :

• kann nicht mehrfach verwendet werden ( AllowMultiple = false ) und
• kann nicht vererbt werden, um Ihre eigene TestInitializeAttribute .
zu erstellen

Also, mein Vorschlag ist, die Methode Test Initialize ohne das Attribut TestInitialize zu erstellen. Dann prüfe in der einzigartigen TestInitialize -Methode, welches der aktuell ausgeführte TestMethod ist und rufe die entsprechende Initialisierungsmethode auf:

Wenn Sie drei Testmethoden haben und jede Methode eigene Initialisierungsschritte hat , warum verschieben Sie dann die Initialisierung in die Methode, die vor jedem Test ausgeführt wird? Nur ein Vorteil, den ich sehe, ist dieser nette Schalterblock, der Ihrer Quelldatei einige Zeilen hinzufügt. Aber es gibt Ihnen einen Nachteil - wenn Sie auf eine dieser Testmethoden schauen, können Sie nicht wirklich sagen, in welchem ​​Kontext die Methode ausgeführt wird. Also verwende ich die Initialisierungsmethode, um nur den Basiskontext einzurichten, der wirklich von allen Tests in der Fixture verwendet wird.

Verschieben Sie einfach die Kontexterstellung in arrange -Teil jeder Methode.

Wenn Sie mehrere Methoden verwenden, die den allgemeinen Kontext verwenden, dann extrahieren Sie einfach die Methode, die den Kontext für sie einrichtet, und rufen Sie sie im arrange -Teil auf. Sie können auch jedes Kontext-Setup in mehrere Schritte aufteilen und diese Schritte wiederverwenden (wie bei Tools, die zu einem bestimmten Zeitpunkt vorhanden sind, wie Specflow ).

Und natürlich, verschiedene Fixtures auch Option zu erstellen.

Es ist ein bisschen wie ein alter Post, aber ich habe folgendes gefunden, was gut zu funktionieren scheint: Definieren Sie zuerst eine Attributklasse:

Definieren Sie dann eine Erweiterungsmethode in einer praktischen Utility-Klasse:

Schreiben Sie nun Ihre Tests, also:

Wenn sie drei separate Eingänge benötigen; dann sollten sie wahrscheinlich in drei separaten Fixtures sein, jede mit ihrer eigenen Init!

Bei meinem Job übergeben wir ein Argument an die TestInitialize-Methode, um zu bestimmen, wie die Initialisierung funktionieren soll.

Wir haben dann eine Standardinitialisierung in der Klassendefinition, die standardmäßig auf "false" gesetzt ist.

Dann können Sie in den Testfällen selbst die TestInitialize für einen beliebigen Test überschreiben.

Wir verwenden einen booleschen Wert, um festzustellen, ob der Admin-Test einen zusätzlichen Overhead für die Einrichtung benötigt. Nehmen Sie dies und wenden Sie die gewünschten Variablen auf eine Weise an, die Ihnen eine mehrfache Initialisierung durch die Verwendung einer Methode ermöglicht.