Wenn ich meine Tests in Visual Studio einzeln ausführen, werden alle problemlos ausgeführt. Wenn ich jedoch alle auf einmal renne, versagen einige. Ich habe versucht, eine Pause von 1 Sekunde zwischen den einzelnen Testmethoden zu setzen, ohne Erfolg.Testen in Visual Studio erfolgreich einzeln, Fehler in einem Set
Irgendwelche Ideen? Vielen Dank im Voraus für Ihre Hilfe ...
Es ist möglich, dass Sie einige gemeinsame Daten haben. Suchen Sie nach statischen Elementvariablen in den verwendeten Klassen. Dies bedeutet, dass ein Test einen Wert festlegt, der einen nachfolgenden Test fehlschlägt.
Sie können auch Komponententests debuggen. Abhängig vom verwendeten Framework sollten Sie in der Lage sein, das Framework-Tool als Debug-Startanwendung auszuführen, wobei der Pfad zur kompilierten Assembly als Parameter übergeben wird.
Es ist sehr gut möglich, dass einige Änderungen/Instanziierungen, die in einem Test durchgeführt werden, die anderen beeinflussen. Dies weist auf ein schlechtes Testdesign und eine unzureichende Isolierung hin.
wie in den anderen Antworten. Es klingt, als ob Sie eine Singleton oder eine globale Variable haben, die die Interaktion verursacht.
Jeder hat wahrscheinlich Recht, einige gemeinsame Datum wird zwischen den Tests geändert. Beachten Sie jedoch die order of MS Test execution. Einfach zwischen den Tests zu pausieren ist keine Lösung. Jeder Test wird in einer eigenen Instanz der Testklasse in einem separaten Thread ausgeführt.
Andere Unit-Test-Frameworks, die ich verwendet habe, arbeiten hart, um sicherzustellen, dass ein Test identische Ergebnisse liefert, unabhängig davon, ob der Test einzeln ausgeführt wird oder als Teil der 'Run all'-Alternative ausgeführt wird. Das Ziel besteht darin, zu verhindern, dass sich ein Test aufgrund von Nebenwirkungen auf einen anderen auswirkt, beispielsweise wenn ein Test den statischen Zustand einer Klasse in einer Konfiguration verlässt, die ein anderer Test nicht erwartet. Das VS-Unit-Testframework scheint diese Isolation nicht zu bieten. Ich habe 2 Vorschläge zur Minimierung der Art von Problemen, die die Frage impliziert. Verwenden Sie zuerst eine nicht statische Klasse anstelle einer statischen Klasse, wenn die Klasse einen Zustand hat (hat etwas anderes als statische Methoden). Erstellen Sie eine einzelne Instanz dieser Klasse, und lassen Sie sie die Statusinformationen beibehalten, die in der statischen Klasse gespeichert wurden. Wenn Sie sich für statische Klassen mit statischem Status entscheiden, verwenden Sie als zweite Methode eine statische Methode, die den statischen Status auf 'leer' zurücksetzt (z. B. eine Methode, bei der alle statischen Eigenschaften auf null/null/etc gesetzt werden). Rufen Sie dies am Ende jedes Komponententests auf, um alle Effekte rückgängig zu machen, die der Test dem statischen Zustand auferlegt hat. (Dies ist zugegebenermaßen weniger elegant, kann aber in Maßen praktikabel sein). Oder tun, was ich vorhabe - finde ein Komponententestframework, das Isolierung über Tests zur Verfügung stellt.
Ich lief auch in dieses Problem, obwohl mein Problem ein Threading-Problem endete. In meinem Fall habe ich das HttpContext-Objekt getäuscht, da die Tests auf seiner Existenz beruhten. Allerdings war ich dies in der ClassInitialize Methode Einstellung dieses Denken würde wie unten für jede Methode verwendet werden:
[ClassInitialize]
public static void ClassInit(TestContext testContext)
{
HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
}
Es stellt sich jedoch heraus, dass jede Testmethode in der Klasse in einem separaten Thread ausgeführt wird. Also musste ich diesen Code zu jeder Testmethode hinzufügen, die sich darauf verließ, um das Problem zu beheben.
[TestMethod]
public void TestMethod1()
{
HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
...
}
[TestMethod]
public void TestMethod2()
{
HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
...
}
Siehe Link für weitere Informationen zu diesem Thema. http://blogs.msdn.com/b/nnaderi/archive/2007/02/17/explaining-execution-order.aspx