Warum führt die Verwendung von NSubstitue.Arg.Any <string> in einer Gruppe von Komponententests dazu, dass der letzte Test in einem anderen Satz fehlschlägt

Question

Wir hatten einen sehr seltsamen Fehler, bei dem die Ausführung unserer vollständigen Unit-Testsuite mit einer Reihe neuer UnitTests immer fehlschlagen würde letzten Testlauf im neuen Abschnitt (mit ReSharper und NUnit für ein Unity3D-Projekt). Wenn Sie jedoch das neue Set selbst ausführen, werden alle Tests bestanden.

Was es merkwürdig machte, war, dass die Änderung der Benennung der fehlgeschlagenen Komponententests dazu führen würde, dass die gesamte Suite in einer scheinbar zufälligen Weise passieren würde. Wir entfernten die Welt "_Multiple" und es schien zu funktionieren, bis wir einen neuen Test hinzufügten und dieser fehlschlug, aber das Wort "_Multiple" überhaupt nicht enthielt. An diesem Punkt wusste ich, dass die Namensgebung ein Ablenkungsmanöver war und nicht wirklich die Ursache des Problems. Es wurde auch auf mehreren Maschinen getestet und hat immer das gleiche Verhalten erfahren.

Wir beendeten das Scheitern Eingrenzung auf, wenn es mit einer Reihe von Unit-Tests durchgeführt wurde, die Arg.Any auf einem Nicht-NSubstitute Objekt verwendet wurde, die

Assert.That(!string.Equals("Desired Value", Arg.Any<string>())); 

im Grunde lief Nachdem wir festgestellt, dass es war klar, dass ich die Arg.Any() -Funktion missbrauchte.

Meine Frage ist, warum würde die Änderung der Namen der Funktionen die Tests überhaupt beeinflussen? Und warum würde das Umbenennen aller Tests nur zu test1(), test2(), test3() usw. dazu führen, dass alle Tests jedes Mal bestanden werden, wenn ein beschreibenderer Name dies nicht tun würde?

Answer 1

NSubstitute tut abscheuliche Dinge mit statischen Zustand, um seine besondere Syntax zu erhalten. Arg.xyz Aufrufe hinzufügen Argumentspezifikationen zu einer globalen Warteschlange, und diese werden gelöscht, sobald ein Anruf an einen Ersatz vorgenommen wird.

Ich vermute, dass das Ändern der Namen der Tests eine Änderung in der Reihenfolge verursacht, in der sie ausgeführt werden, was wiederum dazu führt, dass das Problem offengelegt oder verborgen wird. In einer bestimmten Reihenfolge wird ein Aufruf an einen Ersatz gesendet, der die fehlerhafte Arg.Any<string>()-Spezifikation löscht, während bei einer anderen Reihenfolge die Spezifikation bewirkt, dass ein echter Aufruf als Konfigurieren eines Stub-Werts behandelt wird oder aufgrund eines nicht übereinstimmenden Arguments ausgelöst wird.