Autofixture: NCrunch- und AutoFixture-Integrationsprobleme

Hallo, ich bin der Entwickler von NCrunch.

Gerne erarbeite ich mit Ihnen eine Lösung dafür. Mit dem aktuellen Design fehlen mir leider die Möglichkeiten, das Problem allein auf meiner Seite des Integrationspunkts zu lösen. Ich glaube, dass mein Läufer wahrscheinlich nicht der einzige ist, der Probleme mit dem aktuellen Design hatte.

Wie Sie wahrscheinlich durch die verschiedenen Dokumentations- und Support-Forum-Beiträge, die ich geschrieben habe, verstanden haben, liegt die Ursache des Problems in der zufälligen Generierung von Testparametern durch AutoFixture. Da Testparameter ein kritisches Element bei der Identifizierung eines Tests und seiner anschließenden Ausführung sind, wird die selektive Ausführung von Tests unmöglich, wenn sich die Parameter jedes Mal ändern, wenn ein Test erstellt/entdeckt wird.

Die einzige zuverlässige Möglichkeit, dieses Problem zu lösen, wäre, alle zufälligen Generierungen von Testparametern zu entfernen und stattdessen feste Werte (dh Platzhalter oder consts) zu verwenden oder das Seeding von Parameterwerten anderweitig auf den Testfall selbst zu beschränken. Auf diese Weise wären die Tests immer genau gleich und könnten durchweg als gleich wie jeder andere Test gefunden werden. Jeder Benutzer, mit dem ich zu tun hatte, der AutoFixture für die Parametergenerierung verwendet hat, hat dies für Parameter getan, die ihm für Testzwecke egal sind. Ich hoffe also, dass dieser Ansatz in den Augen des Benutzers keine wirklichen Nachteile hat . Dies hat den Vorteil, dass es auch sofort mit allen Versionen von NCrunch funktioniert und keine Codeänderungen an NCrunch oder einem anderen Runner erforderlich sind.

@remcomulder Vielen Dank für xUnit .

TL DR: xUnit unterstützt solche Theorien und NCrunch sollte sie auch für xUnit unterstützen. Für NUnit - das ist eine offene Frage und ich habe das noch nicht untersucht.

Die von uns verwendete Funktion scheint für xUnit _legal_ zu sein. Wir haben unseren eigenen TestDataDiscoverer , der anzeigt, dass unsere Theorien nicht im Voraus entdeckt werden können (weil wir Zufallsdaten generieren). Später dekorieren wir unser AutoDataAttribute mit diesem Entdecker. xUnit respektiert dieses Attribut und löst Parameterwerte während der Ermittlung nicht auf.

Ich glaube, dass mein Läufer wahrscheinlich nicht der einzige ist, der Probleme mit dem aktuellen Design hatte.

Tatsächlich ist das nicht wahr und sowohl R# als auch VS funktionieren mit solchen Theorien gut. Sie ermöglichen es auch, die jeweilige Theorie erneut auszuführen, selbst wenn sie automatisch generierte Daten enthält. Ich würde vorschlagen, sich auf VS zu konzentrieren, da es auch Erkennungs- und Ausführungsphasen enthält und Open Source ist.

Betrachten Sie den folgenden Testcode:

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

.NET Framework-Testbibliotheksprojekt. VS 2017.3. Zielrahmen: 4.5.2. Installierte Pakete:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

Wenn Sie die Erkennung in VS auslösen, sehen Sie die folgende Ausgabe:

Wie Sie vielleicht bemerken, zeigt VS runner für die Theorien, die die Datenermittlung unterstützen ( StableInlineTest ), die tatsächlichen Daten an, mit denen der Test ausgeführt wird ( 1 ). Bei Tests, die keine Datenermittlung unterstützen und automatisch generierte Daten enthalten ( VolatileTest , VolatileTestWithInline ) entdeckt VS nicht die Theoriefälle und zeigt Ihnen nur die gesamte Theorie. Erst nach der Ausführung können Sie die Werte für diesen speziellen Aufruf sehen:

Jetzt können Sie die jeweilige Theorie erneut ausführen und sie wird _alle Theoriefälle_ erneut ausführen.

Wie Sie sehen können, gibt es tatsächlich eine Möglichkeit, solche Theorien zu unterstützen, und xUnit macht das perfekt. NCrunch sollte der Tatsache Rechnung tragen, dass einige Theoriefälle nicht im Voraus entdeckt werden können. Für solche Theorien müssen Sie die gesamte Theorie wiederholen und nicht einen bestimmten Fall. Ich verstehe nicht, warum das nicht möglich ist.

Die einzige zuverlässige Möglichkeit, dieses Problem zu lösen, wäre, alle zufälligen Generierungen von Testparametern zu entfernen und stattdessen feste Werte (dh Platzhalter oder Konstanten) zu verwenden

Derzeit stellt xUnit keine API zur Verfügung, um den Anzeigenamen zu ändern und generierte Daten durch Platzhalter zu ersetzen. Ich habe ein Problem für sie erstellt (siehe hier ), aber Brads Antwort ist, dass es unwirklich ist und sie schlagen vor, die Erkennung einfach zu deaktivieren, was wir bereits tun.

oder anderweitig das Seeding von Parameterwerten auf den Testfall selbst beschränken.

Leider ist dies für unser Produkt derzeit nicht möglich und viele Dinge sollten umgeschrieben werden, um einen einzigen Samen zu unterstützen.

Mitgliedsdaten

In der Dokumentation hier haben Sie ein weiteres Beispiel (ich habe es in XUnit umgeschrieben):

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

Es ist für xUnit absolut legal, da es das Attribut DisableDiscoveryEnumeration . Es funktioniert wie das obige Beispiel - Theoriefälle werden nicht vorentdeckt.

Die Quintessenz

Es scheint, dass xUnit Instrumente bereitstellt, um zu verstehen, ob der Test flüchtig ist oder nicht (mittels Unterstützung für die Aufzählung vor der Erkennung). Sie können die VS-Implementierung als Beispiel verwenden, um zu verstehen, wie sie damit umgehen und dasselbe in Ihrem Produkt tun. Wahrscheinlich verwenden sie einfach das xUnit SDK und ihre Nachrichtensenken.

Da sowohl R# als auch VS solche Theorien unterstützen, denke ich, dass mit unserem Produkt eigentlich alles stimmt.

Was das NUnit betrifft - lassen Sie uns das später besprechen, da ich das noch nicht untersucht habe. Wahrscheinlich haben wir dafür keine solche API.

Könnten Sie bitte Ihre Meinung zum xUnit-Support angesichts meiner Ergebnisse mitteilen? Wirst du Unterstützung hinzufügen für
xUnit (alle Tests nicht erneut ausführen) und anhalten, um diese Inkompatibilitätswarnung anzuzeigen? 😉

Anscheinend schulde ich Ihnen hier eine Entschuldigung. Der oben beschriebene Anwendungsfall funktioniert aus den von Ihnen erläuterten Gründen unter NCrunch korrekt. Xunit vermeidet eine Voraufzählung der Theorie und fasst sie in einen einzigen Test zusammen, in dem sie sicher identifiziert und ausgeführt wird. Wenn ich dies jetzt teste, kann ich bestätigen, dass NCrunch dies richtig macht. Es scheint, dass wir kein offensichtliches Problem mit InlineAutoData haben.

Ich bin mir nicht sicher, warum dies bei mir früher fehlgeschlagen ist. Ich bin derzeit nicht in der Lage, selbst ein Szenario zu erstellen, in dem es fehlschlägt. Ich weiß, dass mir Benutzer gesagt haben, dass InlineAutoData nicht funktioniert, obwohl ich denke, sie müssen sich melden und Beispiele dafür liefern, wo dies der Fall ist.

Ich möchte Ihre Aufmerksamkeit auf einen bestimmten Anwendungsfall lenken, von dem ich weiß, dass er sowohl NCrunch als auch den VS Runner zerstören wird. Ich gehe davon aus, dass es auch ReSharper und TD.NET beschädigen würde, obwohl ich diese nicht getestet habe, da ich sie nicht installiert habe:

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

Der obige Code schlägt in allen selektiven Ausführungsszenarien fehl. Es wird jedoch bestanden, wenn die Tests im selben Schritt erkannt und ausgeführt werden. Dieses Szenario war der Auslöser für die Warnung von NCrunch zu AutoFixture, da Benutzer dies taten und um Unterstützung baten. Da ich nicht wusste, dass AutoFixture die Voraufzählung deaktiviert, hatte ich (fälschlicherweise) angenommen, dass InlineAutoData gleich ist.

Meine derzeitige Annahme ist, dass Sie ein solches Szenario nicht unterstützen. Ist das richtig?

Wenn ich dies jetzt teste, kann ich bestätigen, dass NCrunch dies richtig macht.

Das ist großartig! Es freut mich zu hören, dass xUnit tatsächlich vollständig von NCrunch unterstützt wird 🎉 Was NUnit angeht - es war immer ungeschickt und wir müssen untersuchen, was wir dort tun können.

Ich beobachte jedoch immer noch Probleme mit NCrunch und AutoFixture. Derzeit habe ich ein xUnit-Projekt mit AutoFixture und wenn ich auch nur eine einzige Zeile ändere, werden alle Tests erneut ausgeführt. Es scheint, dass Sie ein solches Verhalten aktivieren, wenn Sie AutoFixture erkennen, um sicherzustellen, dass nichts übersehen wird.

Ist das so? Wenn ja, könnten Sie das bitte beheben, um ein solches Verhalten für xUnit zu deaktivieren, da dort alles in Ordnung ist?

Ich möchte Ihre Aufmerksamkeit auf einen bestimmten Anwendungsfall lenken, von dem ich weiß, dass er sowohl NCrunch als auch den VS Runner zerstören wird.
Meine derzeitige Annahme ist, dass Sie ein solches Szenario nicht unterstützen. Ist das richtig?

Ja, dieses Szenario wird alle Läufer brechen. Wie jedoch irgendwo in Ihrem Forum richtig darauf hingewiesen wurde, liegt das nicht an der AutoFixture, da Sie so etwas schreiben könnten, was auch nicht funktioniert:

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

Für ein solches Szenario liegt es in Ihrer Verantwortung, die Pre-Discovery manuell zu deaktivieren, sodass sie wie folgt aussehen sollte (achten Sie auf die Eigenschaft DisableDiscoveryEnumeration ):

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

Eigentlich soll es ein sehr seltenes Szenario sein, da wir AutoData und InlineAutoData Attribute für die Datengenerierung haben. Auch AutoFixture ist einfach ein Werkzeug und es liegt in der Verantwortung des Entwicklers, es richtig zu verwenden.

Ich würde NCrunch nicht in einen speziellen Modus versetzen, nur weil es Leute gibt, die das Werkzeug falsch verwenden können. Das Beste, was wir hier tun können, ist, irgendwo ein bekanntes Problem zu platzieren, um dieses spezielle Szenario zu beschreiben und die Leute zu bitten, xUnit richtig zu verwenden (da sie davon vielleicht nichts wissen).

Könnten Sie bitte bestätigen, dass Sie Tests auf besondere Weise ausführen, wenn Sie AutoFixture erkennen, und wenn ja, könnten Sie diesen Modus für xUnit deaktivieren (für NUnit ist es besser, ihn unverändert zu lassen). Wahrscheinlich sollte auch diese Seite aktualisiert werden.

Momentan implementiert NCrunch außer der Kompatibilitätswarnung keine spezielle Behandlung für AutoFixture. Das aufgetretene Verhalten ist wahrscheinlich auf den ausgewählten Engine-Modus zurückzuführen. Es ist vollständig konfigurierbar - wenn Sie in den Modus "Betroffene Tests automatisch ausführen, andere manuell" wechseln, wird sich die Engine meiner Meinung nach so verhalten, wie Sie es erwarten.

Mit dem, was ich von Ihnen gelernt habe, fühle ich mich bereit, die AutoFixture-Warnung vollständig aus NCrunch zu entfernen. Ich war bereits von Anwendern überzeugt worden, es umzuformulieren, da sehr früh klar wurde, dass die Warnung zu weit gefasst ist und einige Funktionen von AutoFixture noch richtig funktionieren. Ich glaube, ich habe die Implementierung von AutoFixture unter xunit ernsthaft missverstanden.

Daher denke ich, dass dies wahrscheinlich ein Best-Case-Szenario für uns ist. Der Anwendungsfall, der mich am meisten kaputt gemacht hat, wird sowieso nicht technisch unterstützt und alles andere funktioniert einwandfrei. In der Zwischenzeit werde ich gerne versuchen, meine eigene Verlegenheit zu vergessen, dies zu einem falschen Ergebnis getestet und verifiziert zu haben, wenn Sie Anlass finden, mir die übereifrige Kompatibilitätswarnung zu verzeihen.

In der Zwischenzeit werde ich gerne versuchen, meine eigene Verlegenheit zu vergessen, dies zu einem falschen Ergebnis getestet und verifiziert zu haben, wenn Sie Anlass finden, mir die übereifrige Kompatibilitätswarnung zu verzeihen.

Kein Problem! Es ist absolut in Ordnung und wir sind alle hier, um uns gegenseitig zu helfen, die Dinge zu verstehen 😅

Mit dem, was ich von Ihnen gelernt habe, fühle ich mich bereit, die AutoFixture-Warnung vollständig aus NCrunch zu entfernen.

Nun, wir haben immer noch Probleme mit NUnit (wir sind aber auf dem Weg ), also scheint diese Nachricht für NUnit-Projekte relevant zu sein. Wahrscheinlich ist es sinnvoll, dies nur für xUnit zu deaktivieren, es sei denn, wir führen die volle Unterstützung für NUnit ein (oder zumindest eine Möglichkeit, diese Unterstützung zu aktivieren).

Ich habe noch eine Sache, die mir unklar ist. Was bedeutet es, dass Sie zB AutoFixture & NUnit nicht unterstützen? Ja, die Testnamen sind jedes Mal anders, aber spielt es eine Rolle, wenn Sie alle Tests wiederholen (wenn der Engine-Modus so eingestellt ist)? Oder bedeutet das, dass Sie die Engine "Nur Auswirkungen" nicht mehr für sie unterstützen? Mein Gedanke war, dass es wahrscheinlich besser ist, sich auf einige bestimmte Szenarien zu beschränken, die wir nicht unterstützen, anstatt No support sagen, während andere in Ordnung sein sollten.

'Betroffene Tests automatisch ausführen, andere manuell'

Ich konnte diese Einstellung in meiner 3.10.0.20 Installation nicht finden. Meinst du die Einstellung Only consider tests 'Out of date' if they are 'Impacted' , die auf true ? Tut mir leid, wenn ich das irgendwo übersehen habe - ich bin ein bisschen neu bei diesem Produkt..

Dokumentations-Update

Es ist wahrscheinlich sinnvoll, den Fall mit xUnit und AutoFixture nicht von dieser Seite zu _entfernen_, sondern stattdessen zu beschreiben, wie man es richtig verwendet (verwenden Sie das Attribut DisableDiscoveryEnumeration ). Es wäre auch cool, das Beispiel "NUnit-Testfall mit inkonsistentem Namen" für xUnit zu beschreiben und zu bitten, das Attribut DisableDiscoveryEnumeration zusammen mit MemberDataAttribute .

Ich habe noch eine Sache, die mir unklar ist. Was bedeutet es, dass Sie zB AutoFixture & NUnit nicht unterstützen? Ja, die Testnamen sind jedes Mal anders, aber spielt es eine Rolle, wenn Sie alle Tests wiederholen (wenn der Engine-Modus so eingestellt ist)? Oder bedeutet das, dass Sie die Engine "Nur Auswirkungen" nicht mehr für sie unterstützen? Mein Gedanke war, dass es wahrscheinlich besser ist, sich auf einige bestimmte Szenarien zu beschränken, die wir nicht unterstützen, anstatt zu sagen Keine Unterstützung, während andere in Ordnung sein sollten.

Dies liegt an der Lebensdauer des Tests unter NCrunch. NCrunch hat einen wichtigen Status, der jedem Test zugewiesen wird (Think Pass/Fail-Ergebnis, Code-Coverage-Daten, Leistungsdaten, Trace-Ausgabe usw.). Diese Daten bleiben so lange bestehen, wie der Test vom Test-Framework „entdeckt“ wird, auch zwischen VS-Sitzungen. Wenn das Test-Framework keinen Test mit derselben Kennung meldet, wird der Test als weg betrachtet und der gesamte Status wird zerstört.

Wenn ein Test mit instabilen Parametern erstellt wird, führt jeder Aufruf des Testframeworks zum Ermitteln von Tests dazu, dass ein ganz neuer Test erstellt wird, da sich der Bezeichner des Tests geändert hat. Das Ergebnis ist, dass jedes Mal, wenn NCrunch NUnit aufruft, um Tests zu entdecken (konsistent nach jedem Build des Testprojekts), alle für Tests mit instabilen Parametern gehaltenen Zustände verworfen werden. Das ist also schlecht. Dies bedeutet, dass die Aufprallerkennung nicht funktioniert und der Motor eine Menge zusätzlicher Arbeit leistet, indem er Tests wiederholt und vorübergehende Ergebnisse durchblättert.

Das Problem geht aber tiefer. Wenn das Ausgeben des Testzustands das einzige wirkliche Problem wäre, könnte die Handhabung für instabile Tests immer noch in dem Sinne "funktionieren", dass sie immer noch von der Engine ausgeführt und Ergebnisse gemeldet würden. Die tieferen Probleme ergeben sich aus der Parallelisierung, der selektiven Ausführung und der verteilten Verarbeitung von NCrunch.

Um eine parallele Ausführung durchzuführen, muss NCrunch mehrere Testprozesse verwenden, die Tests parallel ausführen. Die Mechanik von NUnit ist so, dass Tests entdeckt werden müssen, bevor sie ausgeführt werden können. Dies bedeutet, dass in jedem zur Ausführung verwendeten Prozess ein ganz separater Ermittlungsschritt ausgeführt werden muss. Wenn wir also zwei Prozesse haben, müssen wir die Tests zweimal ermitteln. Wenn die Tests instabile Parameter aufweisen, verfügt jeder Prozess über einen völlig anderen Satz von Tests, wodurch es der Engine unmöglich wird, die vollständige Masterliste der Tests zur Ausführung auf die Prozesse aufzuteilen. Dieses Problem wird auch bei der Verwendung von verteilter Verarbeitung erweitert, da der Remote-Ausführungsprozess auf einer anderen Hardware in einer völlig anderen Umgebung läuft.

Es gibt auch das Problem der selektiven Ausführung. Die Standardbetriebsart von NCrunch besteht darin, immer einen neuen Testprozess zu erstellen, wenn es ausdrücklich angewiesen wird, einen Test durchzuführen. Dies dient dazu, die Schiefertafel zu löschen und mit anderen Läufern so konsistent wie möglich zu sein. Ein solches Feature kann nicht mit instabilen Parametern funktionieren, da das Starten eines neuen Testprozesses das Wiederentdecken von Tests erfordert, die anschließend nicht identifiziert werden können, wenn sich ihre Parameter geändert haben.

NUnit hat sein eigenes internes ID-System, das verwendet werden könnte, um Tests mit instabilen Parametern zwischen Prozessen zu identifizieren, aber dieses ID-System basiert auf der Testgenerierungssequenz (dh es ist inkrementell). Ein solches System kann von keinem Testläufer verwendet werden, der den Teststatus über mehrere Versionen einer Testbaugruppe hinweg verwalten muss, denn wenn der Benutzer einen neuen Test erstellt, fallen alle IDs aus der Reihenfolge und die Daten werden gefährlich irreführend . Die NUnit-Entwickler haben ihr Interesse bekundet, sich von diesem sequenzbasierten System weg und hin zu IDs zu bewegen, die aus den Testattributen selbst generiert werden, was ähnlich wie Xunit wäre (und wahrscheinlich nicht mit instabilen Parametern funktionieren würde).

Ich glaube immer noch, dass der beste Weg, diese Probleme zu lösen, darin besteht, ein konsistentes Seeding der instabilen Parameter durchzuführen. Es gibt immer das Konzept, dass Tests wiederholbar und konsistent sein sollten, was schwer zu erreichen ist, wenn die Tests alle ihre Eingaben vollständig randomisieren. In der Praxis ist ein Test, der zufällig gesetzte Daten für seine Ausführung generiert, bei jeder Generierung ein ganz neuer Test, da sich der Code je nach den zugeführten Daten unterschiedlich verhalten kann.

Ich konnte diese Einstellung in meiner 3.10.0.20-Installation nicht finden. Meinen Sie, dass die Einstellung Nur Tests "Veraltet" berücksichtigen, wenn sie "Betroffen" sind, auf "true" gesetzt werden sollte? Tut mir leid, wenn ich das irgendwo übersehen habe - ich bin ein bisschen neu bei diesem Produkt..

Gehen Sie zum NCrunch-Menü, wählen Sie 'Set engine mode', und Sie sollten die Option dort sehen. Wenn es nicht vorhanden ist, verwenden Sie möglicherweise eine Lösung, die von einer viel älteren Version von NCrunch ausgeführt wurde und nur Legacy-Engine-Modi anzeigt. Das Erstellen einer neuen Lösung irgendwo sollte dies lösen.

@remcomulder Wow! Danke für so eine ausführliche Erklärung! Jetzt sehe ich, dass es in der Tat einfacher ist zu sagen, dass AutoFixture & NUnit derzeit nicht unterstützt wird, da es einige RIESIGE Probleme unter der Haube gibt 😅

Ich glaube immer noch, dass der beste Weg, diese Probleme zu lösen, darin besteht, ein konsistentes Seeding der instabilen Parameter durchzuführen.

Tatsächlich haben wir in dieser PR eine etwas andere Idee. Wir möchten den Testnamen ändern, damit er stabil ist. Zum Beispiel gegebener Test wie folgt:

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

Der Testname lautet:

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

Der Name ist bei jeder Erkennung/Ausführung immer gleich, während die tatsächlichen Argumentwerte sich jedes Mal unterscheiden.

Wie würden Sie diesen Ansatz angesichts Ihrer fundierten Kenntnisse von NUnit bewerten? Wird es für Sie funktionieren? Ich erwarte, dass Sie einen Theorienamen verwenden, anstatt sich an bestimmte Argumentwerte zu binden. Wenn der Testname stabil ist, sollten Sie daher keine Probleme haben, da er jetzt identifizierbar ist. Könnten Sie dies bitte bestätigen, bevor wir mit der Implementierung beginnen? ️

Es gibt immer das Konzept, dass Tests wiederholbar und konsistent sein sollten, was schwer zu erreichen ist, wenn die Tests alle ihre Eingaben vollständig randomisieren.

Wahrscheinlich werden wir eines Tages einen stabilen Seed unterstützen, damit Tests mit den gleichen Argumenten wiederholt werden können, aber derzeit sind wir noch ziemlich weit davon entfernt, daher ist es nicht realistisch 😕 Wir erwarten vielmehr, dass die Aussagen der Benutzer präzise genug sind, um sie später zu verstehen warum der Test fehlgeschlagen ist, auch wenn die Eingabe in einigen Bereichen randomisiert wurde.

Wie würden Sie diesen Ansatz angesichts Ihrer fundierten Kenntnisse von NUnit bewerten? Wird es für Sie funktionieren? Ich erwarte, dass Sie einen Theorienamen verwenden, anstatt sich an bestimmte Argumentwerte zu binden. Wenn der Testname stabil ist, sollten Sie daher keine Probleme haben, da er jetzt identifizierbar ist. Könnten Sie dies bitte bestätigen, bevor wir mit der Implementierung beginnen? ️

Leider ist mein Wissen über NUnit alles andere als tief :( NCrunch nimmt im Grunde nur den Namen NUnit zurück und verwendet diesen, um den Bezeichner zu generieren. Theoretisch also, solange Ihre Lösung den physischen Namen des Tests geändert / stabilisiert hat von der NUnit-API zurückgegeben, dann sollten wir hier in Ordnung sein
zumindest für NCrunch.

Zu beachten ist, dass ein Benutzer möglicherweise mehrere Tests mit derselben Signatur erstellen kann. Wenn die Parameter im Namen auf Rohtypen reduziert werden, wird dies viel wahrscheinlicher/möglicher. Solange Sie sich dieser Szenarien bewusst sind, könnten Sie wahrscheinlich einen Fehler oder etwas anderes einprogrammieren, um dies zu verhindern.

@remcomulder Nur um Sie auf den neuesten Stand zu bringen, damit wir dieses Problem endlich schließen können.

Wie oben beschrieben, wird das xUnit-Framework nativ unterstützt. Für NUnit war das Problem jedoch nicht klar, da es keine Tests mit flüchtigen Namen unterstützt.

Wir haben kürzlich eine PR zusammengeführt und eine neue Version von AutoFixture ( v3.51.0 ) veröffentlicht, die Unterstützung für stabile Namen für NUnit bietet. Für den Moment sind die manuellen Aktionen von der Benutzerseite erforderlich (siehe hier ), aber in v4 werde ich es out-of-the-box machen.

Ich habe gerade getestet und festgestellt, dass NCrunch nur modifizierte Tests ausführen kann, wenn ich den obigen Ansatz verwende, und es scheint, dass es jetzt ordnungsgemäß funktioniert. Ich bin mir nicht sicher, ob einige Aktionen Ihrerseits erforderlich sind (zB das irgendwo dokumentieren). Es wäre auch in Ordnung, wenn Sie das neue Feature testen und uns wissen lassen, ob es jetzt gut funktioniert, damit wir uns ausruhen können 😄

@zvirja Danke, dass du mich darauf

Ich habe jedoch eine Idee, von der ich denke, dass sie uns etwas Zeit beim Benutzersupport sparen könnte. Ein Problem, das wir alle bei Software finden, ist, dass viele Leute die Dokumente nicht lesen, bevor sie ein Tool in die Hand nehmen. Es ist nützlich zu wissen, dass wir sie jetzt bei der Lösung der Probleme mit eindeutigen Namen unter NUnit beraten können, aber der beste Ansatz besteht darin, das Problem immer von selbst lösen zu lassen.

Ich stelle fest, dass AutoFixture standardmäßig den VolatileNameTestMethodBuilder verwendet. Ich akzeptiere dies aus Gründen der Abwärtskompatibilität und stimme zu, dass dies vernünftig ist. Aber was wäre, wenn wir zulassen würden, dass dieser Standard mit einer Umgebungsvariablen überschrieben wird? Wenn wir eine Umgebungsvariable (z. B. 'AutoFixture.FixedTestNames'=='1') angeben könnten, um AutoFixture zu zwingen, VolatileNameTestMethodBuilder zu verwenden, wäre es für einen Runner möglich, den Builder im Voraus anzugeben, ohne dass der Benutzer etwas tun muss. Dies wäre auch ein Bonus für Leute, die mehrere Läufer verwenden, da sie implizit für jeden Läufer unterschiedliche Builder verwenden könnten (ohne Aufwand) und das Beste aus beiden Welten herausholen könnten.

Was denken Sie?

Ich habe diese Arbeit einem kurzen Test unterzogen, und sie sieht für mich solide aus.

Das ist toll! 🎉 Das bedeutet, dass wir dieses Problem schließen können, da jetzt alles gut funktioniert. Vielen Dank für das Testen und Ihre Teilnahme hier 🥇

Was denken Sie?

Ich denke, ich habe eine viel bessere und einfachere Lösung gefunden - wir werden FixedNameTestMethodBuilder in v4 (unserer nächsten Hauptversion) zur Standardstrategie machen, die in den kommenden ein oder zwei Monaten veröffentlicht wird. Die entsprechende PR wurde bereits genehmigt , daher wird der Code vorhanden sein. Daher werden wir sofort einsatzbereit sein und wenn jemand flüchtige Testnamen benötigt, wird er sich manuell anmelden und die Konsequenzen klar verstehen.

Später könnten wir etwas tun, wie Sie es vorgeschlagen haben - eine Umschaltstrategie hinzufügen, die Umgebungsvariablen/AppConfig überprüft, aber ich bevorzuge es, dies nur zu tun, wenn dies tatsächlich erforderlich ist.

Ich glaube, ich habe eine viel bessere und einfachere Lösung gefunden - wir werden den FixedNameTestMethodBuilder zu einer Standardstrategie in v4 (unserer nächsten Hauptversion) machen, die in den kommenden ein oder zwei Monaten veröffentlicht wird.

Das wird gut für mich funktionieren :) Ich bin glücklich! Danke für all Ihre Mühe.

Cool 😉 Nochmals vielen Dank für eure Antworten und Zusammenarbeit 👍

Ich schließe dieses, da von beiden Seiten keine Aktionen mehr erforderlich sind.

@remcomulder @zvirja Ich wollte nur sagen, dass diese Diskussion (die mir geholfen hat, ein ähnliches Problem zu verstehen) und die Hingabe, die Sie hier gezeigt haben, einfach großartig ist! Danke euch beiden für eure tollen Produkte.