Cucumber-js: Szenarioergebnis nicht an Vorher/Nachher-Hooks übergeben

Wurde davon gebissen. Unser Upgrade auf 3 bei cucumber pro ist aus diesem Grund auf Eis gelegt.

Ist https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 der Täter?

Welcher Teil davon wird genau benötigt? Verwenden Sie nur die Statusprädikate? Das scheint das einzige zu sein, was in den Dokumenten zu diesem Thema verwendet wird

Derzeit verwenden wir scenarioResult.status , scenarioResult.scenario.uri und scenarioResult.scenario.line .

@jbpros folgt Ihr Anwendungsfall den Beispielen, die wir derzeit haben (Speichern eines Screenshots, wenn ein Szenario fehlschlägt)? Ich fand es immer sehr seltsam, dass das Szenario in Hooks gereicht wurde und würde gerne einen anderen Weg finden, damit umzugehen.

Derzeit denke ich, dass wir eine neue Support-Code-Funktion hinzufügen: onFailedTestStep der Sie festlegen können, dass eine Funktion aufgerufen wird, wenn ein Testschritt fehlschlägt. Es würde mit dem gleichen Weltargument wie der fehlgeschlagene Schritt aufgerufen und somit könnte man ein Bild oder ähnliches anhängen. Wir könnten ein spezielles Modul erstellen, um Anhänge aus dem Ereignisprotokollformatierer zu analysieren und in einen Ordner zu kopieren.

Als Bastler möchte ich, dass jede solche Funktion / jeder Handler / jedes Objekt so viel Kontext wie möglich hat. Auch ohne etwas Großartiges wie den gesamten Past-and-Future-Run-Tree (https://github.com/cucumber/cucumber-js/issues/875) wäre es äußerst nützlich zu wissen, was der aktuelle Schritt und das aktuelle Szenario sind jedes Versagen.
So kann ich beispielsweise Rollback-Prozeduren anhand von Tags steuern oder einfach sehen, welche anderen Schritte vor dem fehlgeschlagenen ausgeführt wurden.

Ich möchte Sie dringend bitten, diese an onFailedTestStep weiterzugeben, wenn dies die Lösung ist, die Sie verfolgen würden.

Die Hook-Dokumente müssen ebenfalls aktualisiert werden - der Link des ersten Absatzes zu ScenarioResult ist ein 404.

Warum nicht statt onFailedTestStep einen Hook namens AfterStep ? Gurke-Ruby hat das schon lange und wie Sie wissen - Konsistenz ist wichtig.

@aslakhellesoy Ich möchte mich auf den Anwendungsfall konzentrieren und sicher sein, dass wir ihn richtig lösen.

Konsistenz ist wichtig, aber das bedeutet nicht, dass wir alles kopieren sollten, nur weil es woanders existiert. Wir sollten uns weiterentwickeln, wenn wir bessere Wege finden, mit den Dingen umzugehen

Können Sie oder @mattwynne oder jemand aus dem Ruby-Team etwas Licht ins Dunkel bringen, wofür AfterStep gebaut wurde und wofür es verwendet wird?

Ich gehöre nicht zum Ruby-Team, also weiß ich nicht, wofür AfterStep gebaut wurde, aber ich persönlich benutze AfterStep , um verschiedene Operationen durchzuführen. Hier sind einige Beispiele:

1. Machen Sie einen Screenshot und geben Sie das Browserprotokoll bei fehlgeschlagenen Szenarien aus
2. Führen Sie zusätzliche Protokollierung für einige Projekte durch, unabhängig davon, ob es fehlgeschlagen ist oder nicht
3. Aufräumen

Für uns müssen das Szenario und das Ergebnis sowieso an AfterStep werden, um zusätzliche Protokollierung durchzuführen. Ich bin mir sicher, dass es auch andere Anwendungsfälle gibt, die sie in AfterStep benötigen, die wir noch nicht einmal in Betracht gezogen haben.

Das heißt, wenn es so etwas wie onFailedTestStep gäbe, haben wir mehr als eine Möglichkeit, dasselbe zu erreichen: eine mit AfterStep und die andere mit onFailedTestStep .

Dies kann auch innerhalb von Projekten zu Inkonsistenzen führen, je nachdem, wer den Hook implementiert hat; einige können AfterStep während andere onFailedTestStep . Beides halte ich für nicht wünschenswert.

@charlierudolph

Ich möchte verstehen, woher du kommst. Würde es Ihnen etwas ausmachen, zu erläutern, warum Sie Folgendes denken?

Ich fand es immer wirklich seltsam, dass das Szenario in Hooks weitergegeben wurde

Die Vermischung der beiden Paradigmen hat mir nie wirklich gefallen. Vorher / Nachher-Hooks beziehen sich auf Setup / Teardown mit dem tatsächlichen Ausführen der Tests. Die Verwendung auch für die Berichterstattung scheint etwas zu sein, das separat behandelt werden sollte

Machen Sie einen Screenshot und geben Sie das Browserprotokoll bei fehlgeschlagenen Szenarien aus

Wenn Sie dies in AfterStep tun, geschieht dies für fehlgeschlagene Schritte , nicht für fehlgeschlagene Szenarien. Dafür verwenden alle Beispiele im Repository das Szenario-Objekt und deshalb möchte ich einen neuen Hook für diesen speziellen Anwendungsfall erstellen. Ich habe noch keinen anderen zwingenden Anwendungsfall gehört.

Führen Sie zusätzliche Protokollierung für einige Projekte durch, unabhängig davon, ob es fehlgeschlagen ist oder nicht

Welche Art von zusätzlicher Protokollierung führen Sie durch?

Aufräumen

Was ist nach einem Schritt aufzuräumen?

Für uns benötigen wir das Szenario und das Ergebnis sowieso in AfterStep, um zusätzliche Protokollierung durchzuführen. Ich bin mir sicher, dass es auch andere Anwendungsfälle gibt, die sie in AfterStep benötigen, die wir noch nicht einmal berücksichtigt haben.

Ich versuche, diese Anwendungsfälle zu sammeln. Manchmal verwenden Leute es vielleicht, wenn es andere Möglichkeiten gibt, oder als Problemumgehung für etwas, für das wir einen besseren Support einbauen könnten.

Das heißt, wenn es so etwas wie onFailedTestStep gäbe, haben wir mehr als eine Möglichkeit, dasselbe zu erreichen: eine, um AfterStep zu verwenden, und die andere, um onFailedTestStep zu verwenden.

Cucumber-js hat derzeit kein AfterStep und ich plane nicht, beides zu implementieren.

Ich versuche gerade, Gurken-3-Unterstützung im Winkelmesser-Gurken-Framework zu bekommen, und ich könnte wirklich ein AfterStep gebrauchen. Mir ist klar, dass eine Bibliothek, die zwei andere Bibliotheken zusammenfügt, nicht der häufigste Anwendungsfall ist, aber es würde es viel einfacher machen. Ich versuche herauszufinden, wie es mit dem neuen Ereignisprotokoll-Zeug geht, aber ich erhalte in keinem der *-finished Ereignisse einen Funktions-/Szenario-/Schritt-Kontext. Wir verwenden die Namen, Uris und Zeilennummern aus der Funktion, dem Szenario und den Schritten, um dem Winkelmesser Bericht zu erstatten und IDE-Integrationen (Intellij) etwas anzuzeigen und zu navigieren in ihrem Baum. Meine 0,02 Dollar sowieso.

Um nur zu erwähnen, dass alle besprochenen Funktionen (und vieles mehr) mit setDefinitionFunctionWrapper .
Sie können alle Schritte mit Pre/Post-Aktionen umschließen, mit denen Sie nicht nur auf die Ein- und Ausgänge eines Schritts reagieren, sondern diese sogar mutieren können.

So verwende ich es zum Beispiel, um einen "Der nächste Schritt sollte mit Fehler XYZ fehlschlagen" Schritt zu implementieren, der es mir ermöglicht, schnell tiefe Negativprüfungen und Fehlersimulationen zu implementieren, ohne doppelte Negativschritte oder spezielle umkehrbare Fehlerbehandlung in jedem einzelnen Schritt zu implementieren .

Ich denke, es gibt nichts, was ein AfterStep Hook tun kann, was setDefinitionFunctionWrapper nicht kann.

Irgendwelche Updates dazu? Ich versuche bei der Arbeit von 2.0.0 auf 3.0.0 zu aktualisieren und werde immer noch undefiniert für das SzenarioResult

@paul-phillips-ark ja, siehe #905. Wenn Sie helfen möchten, es voranzubringen , können Sie abzweigen und eine neue @charlierudolph adressiert.

Wenn ich console.log(scenarioResult) habe, erhalte ich immer noch undefiniert in den Vorher- und Nachher-Funktionen? Verpasse ich etwas? Entschuldigung, wenn der obige Kommentar dicht klingt.

Meine Anwendungsfälle sind derzeit folgende:

Vor jedem Szenario fordere ich Fixtures an, die meine Datenbank zum Testen füllen. Jedes Feature hat seinen eigenen Satz von Fixtures, die dafür benötigt werden. Der Pfad des Geräts auf dem Server wiederholt den Pfad der Funktion, daher brauche ich auch die Option uri :

Before({ timeout: 60 * 1000 }, scenarioResult => {
    ...
    const file = scenarioResult.scenario.feature.uri;
    ...
});

Am After Hook mache ich wie viele von uns einen Screenshot:

After(scenarioResult => {
    if (scenarioResult.status === 'failed') {
      driverUtils.takeScreenShot(scenarioResult.scenario.name);
    }
});

@charlierudolph könntest du ein Release mit Pull Request #905 als Zwischenlösung kürzen? es ermöglicht uns, den Übergang von v2 zu v3 abzuschließen, der derzeit aufgrund dieser Regression/Änderung feststeckt. Ihr vorgeschlagenes Refactoring könnte in einen anderen Pull-Request einfließen.

Es gibt einige Probleme für #905, aber ich werde versuchen, eine Lösung zu finden und dieses Wochenende eine Veröffentlichung zu veröffentlichen.

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.