Cucumber-js: Ergebnis fehlt Szenario & Tags

Nö. Sie können nicht ohne weiteres auf die Tags des Testfalls zugreifen. Es ist nicht geplant, zum alten Szenarioergebnis zurückzukehren. Was ist Ihr Anwendungsfall, um die Tags zu benötigen?

In meinem Fall habe ich eine Abhängigkeit vom Tag-System. Um einige Daten in den Afterhooks zu erhalten.

Etwas wie das:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

Sie können Hooks erstellen, die nur für Szenarien mit bestimmten Tags ausgeführt werden: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

Ich habe auch mehrere Anwendungsfälle, um die Szenario-Tags zu kennen. Angesichts des folgenden Sudo-Beispiels (fehlende Versionssyntax, da ich Testfälle in 1.3.1 habe und die neueste Version 3.0.1 anschaue):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

Ich habe ein Tag, das angibt, wann der Hook ausgeführt werden soll, und ich habe andere Tags, die als Daten fungieren, um den Hook für andere Anwendungsfälle dynamischer zu machen. Ansonsten erstelle ich den gleichen Hook mit der gleichen Logik und ändere nur die Daten, die ich ihm übergebe. Ich finde es sehr nützlich, die Tags zu kennen und ein sehr mächtiges Werkzeug, um Hooks flexibler zu machen.

Kann ich hier auch fragen, ich kann das Ergebnisobjekt anscheinend nicht im After-Hook in 3.0.1 erhalten. Ich habe testCase, SzenarioResult und Szenario ausprobiert. Verpasse ich etwas?

Wir haben einen Fall, in dem wir unsere Testfälle in TestRail aufbewahren und sie vor dem Lauf herunterladen und als Feature-Dateien speichern.

Im After-Hook senden wir dann detaillierte Testergebnisse an unsere SQL-Datenbank. Zu diesen Ergebnissen gehören:

• Feature-ID von TestRail - entnommen aus einem Tag (jedes Feature hat ein automatisch generiertes Tag mit Feature-ID)
• Ausnahme, die geworfen wurde - entnommen aus scenario.getException() in Gurke 1.x
• alle Tags, mit denen das Feature getaggt ist
• Schritte, die fehlgeschlagen sind - wir verwenden den stepResult Hook, um das Ergebnis jedes Schrittes zu erhalten
• eine Reihe anderer Informationen, die von TestRail mithilfe der aus Tags entnommenen Feature-ID abgerufen wurden

Mit der aktuellen Änderung in cucumber 3.x werden wir also nie in der Lage sein, zu wechseln, da unsere Infrastruktur vollständig zerstört wird.

@pawelus Meine Infrastruktur macht genau dasselbe.
Da Sie bei der asynchronen Ausführung dieser Aktionen nichts verlieren (dh Ihre eigentliche Testinfrastruktur kümmert sich nicht um das TestRail-Update), können Sie diesen Code in einen benutzerdefinierten Formatierer verschieben und die Informationen aus dem Ereignis verwenden Protokoll zum Erstellen und Senden der Berichte.

Persönlich habe ich ein Wrapper-Skript, das Gurke startet.
Es lädt die TestRail-Szenarien herunter, bevor Gurke gestartet wird, daher war es für mich kein großes Problem, den TestRail-Berichtscode aus den Gurken-Hooks in das Wrapper-Skript zu verschieben.
Nachdem cucumber abgeschlossen ist, liest das Skript das ausgegebene cucumberResults-JSON und kompiliert von dort alle benötigten Informationen.

Klingt so, als müssten Sie Ihren Code so oder so neu anordnen.
Ich denke, das Verschieben aller Pre/Post-Aktionen in ein Wrapper-Skript ist eine nette Lösung, die einen Teil der Kontrolle wiederherstellt, die wir in V3 verloren haben.
Es ist immer noch etwas mühsam, da ich wichtige Kontextinformationen serialisieren muss, um die ausgegebenen Ergebnisse anzureichern (da mein Infrastrukturzustand zerstört wird, wenn der entsprechende Code ausgeführt wird), aber es ist machbar.

Ich denke, es wäre eine Schande, die Fähigkeit zu verlieren, Tags in Hooks zu kennen. Es war die einzige Möglichkeit, etwas konfigurierbarer zu machen, da Sie keine Parameter übergeben können. Ich fügte zusätzliche Tags hinzu und sah dann, welche auf das aktuelle Szenario angewendet wurden, um Funktionen mit unterschiedlichen Eingaben aufzurufen.

@yaronassa wir führen unsere Tests über Protractor durch, wir starten Gurke nicht direkt, also gibt es hier noch eine weitere Abstraktionsebene, die man zählen kann.

Wir laden Funktionen herunter, bevor Protractor startet, wie Sie es tun, aber das Senden von Ergebnissen an die Datenbank ist eine andere Geschichte.

Mit Sharding und Tests, die auf Selenium-Grid ausgeführt werden, und Wiederholungen von fehlgeschlagenen Funktionen wird es ziemlich mühsam und eine komplexe Logik sein, die Ergebnisse in der richtigen Reihenfolge in der Datenbank zu erhalten. Ziemlich viel Arbeit, um die Fähigkeiten wiederherzustellen, die wir in Gurke 1 und 2 hatten.

Auch das Erstellen eines benutzerdefinierten Formatierers, nur um Schrittergebnisse zu erhalten, klingt einfach nicht richtig.

Hallo, ich bin bei dir.
Ich hätte mir uneingeschränkten Zugriff auf den aktuellen Status der Gurke gewünscht - Feature, Szenario und Schritt mit seiner gesamten Eigenschaftssammlung und Schreibzugriff (ich hätte sogar Zugriff auf den zukünftigen "Aufrufstapel" der Szenarien, mit der Möglichkeit, ihn vorher zu manipulieren ).

Da sich cucumberJS bewusst von dieser Art der "inneren Sichtbarkeit" entfernt, biete ich Lösungen an, von denen ich denke, dass sie in absehbarer Zeit funktionieren können. Persönlich denke ich, dass es eine Zeit kommen wird, in der Tüftler wie wir auf überschreibende innere Methoden in Cucumbers internem zurückgreifen müssen, um diese Art von Zugang zu erhalten.
Und das ist in Ordnung - ich denke, wir sind ein Dutzend und Tausende von Gelegenheitsnutzern.

Wenn möglich würde ich auch den Namen des Szenarios unterstützen. Tatsächlich füge ich eine Snapshot-Funktion hinzu und ich muss den Namen des Szenarios kennen, um meine Snapshots zu benennen.

@gd46 Sie könnten Folgendes tun:

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

Das hat keine Duplizierung außer dem @set_video Flag.

@pawelus

Im After-Hook senden wir dann detaillierte Testergebnisse an unsere SQL-Datenbank.

Müssen Sie dies in einem After Hook tun? Könnten Sie dies tun, nachdem Ihre Tests abgeschlossen sind, indem Sie die Ergebnisse des Json-Formatierers analysieren? Sie können den Ereignisprotokollformatierer verwenden, um dies fortzusetzen, wenn Ergebnisse auftreten, obwohl dies etwas mehr Verarbeitung erfordern würde. Ein Nebenprodukt der 3.x-Änderungen ist, dass die Analyseergebnisse aus den Unterstützungsdateien und in eigenständige Prozesse verschoben werden. Ich denke, dies ist eine bessere Trennung der Dinge und idealerweise, wie die Dinge ursprünglich gebaut wurden.

@bnadim

Sie könnten Screenshots mit der Funktion attach hinzufügen, damit sie in den Event-Potocol/Json-Formatierern ausgegeben werden und dann eine Nachbearbeitung durchführen, um diese basierend auf dem Szenarionamen in Dateien zu speichern. Seite nicht: Der Szenarioname ist nicht garantiert eindeutig, während die Szenario-URI und die Zeilennummer dies sind.

@charlierudolph Ich nehme an, das ist eine solide Ersatzlösung für meine Bedürfnisse. Außerdem entfällt die Notwendigkeit, das aktuelle laufende Szenario zu analysieren. Es kann nur dazu führen, dass mehrere Kombinationen von Hooks definiert werden, die die verschiedenen Kombinationen berücksichtigen, die eine bestimmte Funktion innerhalb eines Hooks verarbeiten kann.

So habe ich zum Beispiel ähnliche Beispiele, in denen ich die Tags der aktuellen Ausführungsszenarien erhalte, die sie basierend auf einem Muster aufteilen und einen Teil der Übereinstimmung als Parameter für eine Funktion verwenden. In diesen Fällen sind alle Schritte, die ausgeführt werden müssen, gleich und das einzige, was sich ändert, ist der Parameter. Dies würde also mehrere Setup-Schritte im Hook reduzieren, so dass es für mehrere Fälle funktionieren könnte.

Ein solches Beispiel:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

Teilen Sie mir Ihre Meinung dazu mit? Ich glaube, Ihr Beispiel wäre in einigen Fällen ein einfacher Ersatz. In anderen Fällen, in denen mehrere zusätzliche Schritte erforderlich sind, können Sie jedoch möglicherweise alle diese Schritte duplizieren.

Mein Anwendungsfall ist, dass ich für jedes Szenario einen Mockserver einrichte, basierend auf dem Tag, von dem ich weiß, wie es sich verhalten soll. Das Hinzufügen von Hooks für bestimmte Szenarien mit Tags ist sehr wartungsintensiv, da ich für jedes Szenario, das ich unterstütze, einen Hook hinzufügen muss...

Wir verwenden das Szenario.name auch in unseren Vorher- und Nachher-Hooks, um den Namen des Szenarios zu protokollieren. Auf diese Weise können wir bei der Analyse von Testergebnissen sehen, wann ein bestimmtes Szenario beginnt und endet. Diese Änderung unterbricht diese Funktion.

Ich verwende Cucumber-js, um Selenium zu fahren. Sowohl lokal als auch Browserstack

Ich habe den Teststatus (Feature, Szenario, Tags, Ergebnisse usw.) in den Hooks für viele wichtige Dinge verwendet.

• um szenariospezifische Änderungen der URL zu haben
• Tests basierend auf der aktuellen Browserkonfiguration dynamisch überspringen
• Verwenden Sie eine szenariospezifische URL, um Testergebnisse zurück in den Browserstack aufzunehmen
• Verwenden Sie Funktions- und Szenarionamen, um Sitzungsnamen im Browserstack zu generieren
• Analysieren Sie Tags, um szenariospezifische Browserauflösungen zu identifizieren und festzulegen

All dies wurde in Apps verpackt, um gleichzeitige Instanzen zu ermöglichen, um die Gesamtlaufzeit zu reduzieren.

Warum wurden diese fallen gelassen?
Kommen sie nie wieder?

@gd46

Beinhaltet das ausgeführte Szenario diese Art von Profil? Vielleicht könnten Sie das Szenario speichern lassen, welcher Profiltyp mit der Welt interagiert, und dann haben Sie ein einziges klares Tag, das zum Entfernen des gespeicherten Profils auffordert?

@justusromijn

Könnten Sie für Ihren Mock-Server das Setup von Tag-basiert auf einen Schritt verschieben, der definiert, was das Setup ist? Dann können Sie einfach parametrieren.

@Jordyderuijter

Sie können die Szenariozeile und die uri (die eigentlich eindeutig ist und Sie nicht nach dem Szenarionamen suchen müssen) protokollieren.

@leggebroten

um szenariospezifische Änderungen der URL zu haben

Sie können stattdessen einen Schritt dafür verwenden oder eindeutige Tags verwenden

Tests basierend auf der aktuellen Browserkonfiguration dynamisch überspringen

Wie haben Sie Tests dynamisch übersprungen? #912 fügt Unterstützung dafür hinzu

Verwenden Sie eine szenariospezifische URL, um Testergebnisse zurück in den Browserstack aufzunehmen

Sie können anstelle des Namens die Zeile und die uri verwenden. Wie bereits erwähnt, sind Zeile und uri garantiert eindeutig, der Name jedoch nicht. Ich schlage auch vor, den Json-Formatierer oder den Ereignisprotokollformatierer für Testergebnisse zu analysieren und Anhänge zu verwenden, wenn Sie etwas hinzufügen müssen.

Verwenden Sie Funktions- und Szenarionamen, um Sitzungsnamen im Browserstack zu generieren

Sie können die Zeile + URI . verwenden

Analysieren Sie Tags, um szenariospezifische Browserauflösungen zu identifizieren und festzulegen

Dazu können Sie einen Schritt verwenden.

Von all diesen Beispielen habe ich noch einen Anwendungsfall, der mich überzeugt, dass wir dem Hook Tags oder einen Namen hinzufügen sollten. Die Tags und der Name scheinen bestimmte Dinge einfacher gemacht zu haben, aber ich denke, es gibt andere Möglichkeiten, sie zu erreichen, die für mich sinnvoller sind

@charlierudolph danke für die Antwort. Für den Mockserver hatte ich bereits ein kurzes Gespräch mit einigen Kollegen und die Verwendung eines gemeinsamen "Hintergrunds" war für eine Lösung in Betracht gezogen, also kannst du das auf der Liste ja kreuzen.

@charlierudolph Danke für die Antwort.

Ihre Vorschläge zur Verwendung von Schritten und zur Analyse der Ausgabe könnten zwar funktionieren, sind jedoch früheren Versionen weit unterlegen, bei denen Rückrufe Zugriff auf den Teststatus haben.

0) Inkonsistent mit dem Beobachtermuster. Rückrufe sollten die Daten erhalten, die sie für das unterstützte Verhalten benötigen

1) Verursacht extreme Zerbrechlichkeit. Tests sollten zuverlässig sein, sonst wird ihnen nicht vertraut. Zeilennummern und Dateinamen ändern sich. Durch einfaches Hinzufügen oder Entfernen eines Wagenrücklaufs werden Tests abgebrochen.

2) Die Verwendung von Schritten zum Ändern des Zustands verstößt gegen DRY. Betrachten Sie den häufigen Fall des Hinzufügens von A/B-Tests, die mit einem Tag gekennzeichnet sind. Sofern Sie keine Befehlszeilenerweiterung hinzufügen, um Tests basierend auf den darin enthaltenen Schritten auszuführen, erfordern Tests BEIDE Tag und ihre unterstützenden, zustandsverändernden Schritte.

3) Erfordert vom Entwickler zusätzliche Arbeit. Das Parsen der Ausgabe, um den Zustand zu finden, ist unnötig, mühsam, fehleranfällig, bindet Tests an Ausgabeformate (schlechte Kopplung) und verstößt gegen DRY.

4) Inkonsistent mit Gurke. Das Hinzufügen von Schritten (ein semantischer Teil des Tests), um den Status des Features zu ändern, widerspricht der Absicht von Cucumber, den Testautor zu isolieren. Wenn sich das Verhalten nicht geändert hat, sollte der Test dies nicht tun.

5) Es ist nicht deklarativ. Tags sind Metadaten ÜBER den Test. Es ist semantisch konsistent, sie zu verwenden, um den Status zu ändern, in dem der Test ausgeführt wird. Während Schritte in den Test eingebettet sind. Sie identifizieren eine Reihe von Tests durch ihre Tags … nicht die Schritte, die sie verwenden.

Oh, und ich habe Tests nicht wirklich "übersprungen", ich habe callback ( null, 'pending' ) verwendet, um die Ausführung des Tests zu vermeiden. Die neue 'Skip'-Funktion ist eine überlegene Lösung.

@charlierudolph , ich dachte, eine andere Lösung ...
Geben Sie beim Erstellen des World-Objekts einen Verweis auf das für den Test verwendete Szenario-Objekt an.

Da die Welt für alle Callbacks als "this" verfügbar ist, würde sie volle Parität mit V2 erreichen (vorausgesetzt, AfterAll-Callback wurden die Ergebnisse gegeben).

@leggebroten

1. Ich habe nie gehört, dass das Beobachtermuster ein Designziel für Gurken ist.
2. Szenarionamen sind auch fragil, da eine einzelne Zeichenänderung sie ebenfalls ändert. Ich stimme dem Umbruch der Datei-/Zeilennummer zu, wenn ich Aktionen ausführe, die sich wie nicht zusammenhängende Aktionen anfühlen. Ich habe die Verwendung bei der Berichterstellung von Ergebnissen und nicht bei der Durchführung von Tests vorgeschlagen, und daher hat der zerbrechliche Teil keine großen negativen Auswirkungen.
3. Using Steps to alter State violates DRY Ich verstehe das nicht. Das Tag wird zum Auswählen von Funktionen verwendet und der Schritt wird für Setup/Aktionen/Erwartungen verwendet. Dies sind unterschiedliche Zwecke. Wir haben minimale Unterstützung für die Verwendung des Tags für die Einrichtung mit markierten Hooks, aber es ist nicht für Komplexität ausgelegt.
4. Ich habe nur vorgeschlagen, die Formatierungsausgabe für die Berichterstellung zu analysieren. Das sollte bei laufenden Tests nicht involviert sein.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer Ich verstehe das auch nicht. Wenn Sie keine Schritte zum Ausführen von Aktionen und zum Festlegen des Status verwenden können, wie führen Sie dann Tests durch?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . Ich bin anderer Meinung, dass das konsequent ist. Tags dienen mir nur zur Identifizierung von Tests. Es gibt Unterstützung für minimale Zustandsänderungen, aber nicht für komplexe Zustandsänderungen mit Parametern.

Es gibt kein Szenarioobjekt mehr im System. Ich denke nicht, dass Parität mit v2 ein Ziel sein sollte. Ich bin froh, dass dieses Gespräch zustande kam und suche nach anderen Lösungen, aber ich möchte nicht zu dem zurückkehren, was wir zuvor hatten, da ich glaube, dass sich die Benutzer viel mehr auf die Implementierung von Gurke und nicht auf die Benutzeroberfläche verlassen.

@charlierudolph ,

Vielen Dank, dass Sie sich die Zeit genommen haben, dieses Thema zu besprechen. Ich schätze die Arbeit, die Sie geleistet haben, um uns Cucumber-js zur Verfügung zu stellen, sehr zu schätzen. Aber so wie es aussieht kann ich nicht auf V3 upgraden.

Ich habe nicht vor, kämpferisch zu sein. Ich mache mir nur Sorgen und es könnte in meinen Antworten herauskommen.

Ich habe nur die dokumentierte Ereignisschnittstelle aus der vorherigen Version verwendet und ein Framework erstellt, das die Gesamttestlaufzeit drastisch reduziert, indem es ermöglicht, dass Funktionen gleichzeitig über eine riesige, konfigurierbare Testmatrix ausgeführt werden, die Betriebssysteme/Versionen, Browser/Versionen, Desktop/ Mobile und Optimizely A/B-Tests.

Ich kann Schritte nicht verwenden. Es ist zu spät. Der Gerätetyp, das Betriebssystem/die Version und der Browser/die Version MÜSSEN bestimmt werden, bevor der Test beginnt, oder jedes Szenario muss einen Schritt "Betriebssystem einrichten" und einen Schritt "Browser einrichten" haben. Dies steht in direktem Konflikt mit den Zielen von Cucumber.

Alternativ können Sie, wie bereits erwähnt, dem World-Konstruktor die Szenarioinformationen (Feature-URI, Name, Zeile und Tags) bereitstellen. Dies stimmt semantisch mit der Absicht des Weltobjekts überein und ist einfacher zu kapseln und zu erweitern. Dadurch werden nicht nur die meisten meiner Event-Handler eliminiert, sondern weil das "this" des Handlers das World-Objekt ist, ist es zustandskonform mit dem Beobachtermuster.

1. Ich habe nicht gesagt, dass das Observer-Muster ein Designziel für Gurke ist. Nur, dass Hooks und Events Beobachter sind und ihnen als solche der Status gegeben werden sollte, den sie für ihre Arbeit benötigen. Dieses Muster ermöglicht die Trennung zwischen der Implementierung des Aufrufers und den Ereignishandlern.

2. Ich habe keine Abhängigkeit von den tatsächlichen Namen. Da sie jedoch einzigartig sind, sind sie das Mittel, um den zugehörigen benutzerbedeutungsvollen Sitzungsnamen im Browserstack zu erstellen.

3. Der Zugriff auf den Satz von Tags während Before ermöglichte es mir, wiederverwendbare Konstrukte zum Ändern des Status (wie das Festlegen von Optimizely-URL-Parametern) zu erstellen, ohne den Test zu ändern (Schritte hinzuzufügen). Dies bedeutete, dass es eine 1-1 Korrelation zwischen den Tests, die ich ausführen wollte (Tags) und deren Einrichtung gab. TROCKEN.

4. Sie haben Bedenken geäußert, dass Entwickler von der Implementierung abhängig werden, aber Ihre Lösung zum Entfernen des erforderlichen Observer State besteht darin, den Entwickler von einer anderen Implementierung (Dateiformat) abhängig zu machen? Wie kann es besser sein, einen Benutzer zu zwingen, VIEL mühsamer, langsamer und fehleranfälliger beim Analysieren von Dateien zu arbeiten, als auf eine State-Eigenschaft zuzugreifen?

5. Offensichtlich setzen Schritte den Teststatus. Aber eines der Designziele von Cucumber war es, die Person, die die Schritte schreibt, von der zugrunde liegenden Implementierung zu isolieren. EG testet semantisches Verhalten, ohne sich in den zugrunde liegenden Details zu verzetteln. Das Hinzufügen von Schritten zum Ändern von Abfrageparametern und das Definieren von Gerät/Browser/OS scheint diesem Ziel zu widersprechen.

6. Für Sie geht es bei Tags nur darum, Tests zu identifizieren. Aber Gurken-Wiki hat viele Verwendungsmöglichkeiten für Tags.

7. Organisieren und Gruppieren
8. Filter (Ausführung von Sets über die Kommandozeile)
9. Links zu verwandten Dokumenten (wie Optimizely-Flags)
10. Angeben, wo sich das Feature im Prozess befindet

Der Zugriff auf die Tags während des Vor-Rückrufs ermöglicht es mir, den geeigneten Status basierend auf der Browserkonfiguration sicherzustellen, die zum Ausführen des Tests verwendet wird. Die Verwendung von Tags macht das deklarativ. Die Verwendung von Schritten verschleiert die Absicht

Die Aufrufe und Parameter der Event-Handler in früheren Versionen waren eine Schnittstelle. Wenn Entwickler, die ihren Code mit Ihrer Implementierung koppeln, durchsickern, übergeben Sie einen schreibgeschützten „Szenario“-Proxy an die Ereignishandler.

@charlierudolph danke für deine Antwort

Szenarionamen sind auch fragil, da eine einzelne Zeichenänderung sie ebenfalls ändert. Ich stimme dem Umbruch der Datei-/Zeilennummer zu, wenn ich Aktionen ausführe, die sich wie nicht zusammenhängende Aktionen anfühlen. Ich habe die Verwendung bei der Berichterstellung von Ergebnissen und nicht bei der Durchführung von Tests vorgeschlagen, und daher hat der zerbrechliche Teil keine großen negativen Auswirkungen.

Szenarionamen sind zwar auch fragil, aber es ist viel weniger fragil, auf Szenarios zu verweisen, als sie per Datei und Zeile zu referenzieren. Wir verwenden die Szenarionamen in der Protokollierung täglich, um Fehler im Lauf zu analysieren und zu sehen, was schief gelaufen ist. Wenn die Protokollierung nur die Datei- und Zeilennummer anzeigt, verursacht dies viel zu viel Aufwand, um das Szenario zurückzuverfolgen. Außerdem wird es noch komplizierter, wenn jemand in der Zwischenzeit Änderungen in der Feature-Datei vorgenommen oder das Szenario an eine andere Stelle verschoben hat.

Wenn die Protokollierung nur die Datei- und Zeilennummer anzeigt, verursacht dies viel zu viel Aufwand, um das Szenario zurückzuverfolgen.

Wie ist es mehr Overhead? Sie kennen die Datei- und Zeilennummer und können direkt dorthin gehen. Wenn Sie den Szenarionamen haben, müssen Sie nach dieser Zeichenfolge suchen, die in diese Datei und Zeile übernommen wird.

Wie ist es mehr Overhead? Sie kennen die Datei- und Zeilennummer und können direkt dorthin gehen. Wenn Sie den Szenarionamen haben, müssen Sie nach dieser Zeichenfolge suchen, die in diese Datei und Zeile übernommen wird.

Wie gesagt, wenn sich die Feature-Datei zwischenzeitlich geändert hat und das Szenario nicht mehr in dieser Zeile positioniert ist. Vor allem, wenn ich die Protokolle eines älteren Testlaufs durchschaue (zB vor 1 Woche). In diesem Fall müsste ich git durchgehen und sehen, welches Szenario zu diesem Zeitpunkt in dieser Zeile war.

FWIW, Gurke-Rubin hat zwei Erweiterungspunkte, von denen ich denke, dass sie dem Prinzip "einfache Dinge sollten einfach sein, schwierige Dinge sollten möglich sein" entsprechen und Ideen sein könnten, die bei diesen Anwendungsfällen helfen könnten.

Zunächst übergeben wir jedem Hook eine Instanz von RunningTestCase . Dies ist ein unveränderliches Wertobjekt, das alle Informationen über die Gherkin-Quelle (Szenario / Gliederung / Tags usw.) sowie den aktuellen Ergebnisstatus des Szenarios enthält. Unveränderlich zu sein bedeutet, dass wir davor geschützt sind, Fälle in Betracht zu ziehen, in denen der Benutzer versuchen könnte, Dinge an uns zu ändern, aber es gibt ihm gleichzeitig Transparenz über den aktuellen Stand der Dinge.

Zweitens haben wir Filter . Mit Filtern können Sie den Stream von Testfällen vor deren Ausführung bearbeiten. Wir verwenden Filter, um beispielsweise Testfälle aus dem Stream zu entfernen, die nicht dem in der CLI angegebenen Tag-Muster entsprechen. Filter sind eine Power-User-Funktion.

HTH

Ich habe gerade festgestellt, dass die Dokumentation hinter diesem Link für Filter schrecklich ist! Es tut uns leid. Keine Zeit, das Problem jetzt zu beheben, aber hier gibt es einige weitere Beispiele: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Hallo @charlierudolph ,

Es tut mir leid, dass es eine Weile her ist, dass ich dieses Gespräch verfolgt habe. Können Sie Ihre Aussage präzisieren:

"Beinhaltet das ausgeführte Szenario diesen Profiltyp? Vielleicht könnten Sie das Szenario speichern lassen, welcher Profiltyp mit der Welt interagiert, und dann haben Sie ein einziges eindeutiges Tag, das zum Entfernen des gespeicherten Profils auffordert?"

Ich bin mir nicht sicher, ob ich folge.

Und ich verstehe, dass es vielleicht andere Möglichkeiten gibt, die gleiche Lösung ohne das alte Testergebnis zu erhalten. Aber was ich bisher in diesem Gespräch gesehen habe, ist, dass alle Alternativen komplexer erscheinen, als sie sein müssen. Das alte Testergebnis enthielt viele beschreibende Daten über das Szenario, das ausgeführt werden sollte, und es war die einzige Möglichkeit, Hooks "parametrisiert" zu haben. Nach dem, was ich gesehen und ausprobiert habe, unterstützt der Winkelmesser derzeit nicht das Ausführen einer Funktion über eine Szenario-Zeilennummer. Das neue Testfallergebnis hat also nicht viel, was ich außer dem Status nützlich finde.

Ich möchte, dass testCase mit dem zurückgegebenen Ergebnis übereinstimmt, wenn getTestCasesFromFileSystem mit PickleFilter verwendet wird. Ich habe dies verwendet, um einige interessante parallele Arbeiten durchzuführen, um das Filtern von Szenarien nach Tags zu unterstützen, um sie als Shards an den Winkelmesser weiterzugeben. Die von diesem Ergebnis zurückgegebenen Informationen sind weitaus nützlicher und ich denke, es wäre äußerst nützlich, sie im Testfallergebnis zu haben.

Beispielergebnis von PickFilter:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

Ich sage nicht, dass es genau übereinstimmen muss, aber ich sehe viel in diesem Ergebnis, von dem andere hier und ich zu profitieren scheinen.

Wenn Sie in meinem Beispiel interessant sind, verwende ich es hier: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph Wird hier testCase festgelegt?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

Soweit ich das beurteilen kann, gibt es neben testCase einen Hinweis auf Pickle. Warum also nicht noch ein paar Bits aus dem Pickle-Ergebnis in das Testfall-Ergebnis zurückgeben?

@gd46 Okay, fügen pickle zu dem Objekt hinzu, das an den Hook übergeben wird und sourceLocation ersetzt. Das muss in dieser Funktion aktualisiert werden: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

Hallo @charlierudolph , ich habe gerade deinen Kommentar gesehen. Das wäre toll! Ich werde versuchen, mir das demnächst anzuschauen. Den Beitrag übernehme ich gerne.

@charlierudolph Wollte nur die Änderung verdeutlichen. Sind wir in Ordnung mit dem Unterschied, dass pickle uri enthält, ohne dass die Zeilennummer direkt darauf steht, wie dies bei sourceLocation der Fall ist. Und wenn jemand die uri mit der Zeilennummer konsumieren möchte, kann er die vom pickle-Objekt zurückgegebenen Zeilennummern verwenden? Ich sehe kein Problem damit, wollte es nur bestätigen.

Ich denke, lassen Sie uns das Quellpositionsobjekt unverändert (anstatt es zu entfernen) und fügen Sie das pickle-Objekt hinzu.

Ok das funktioniert bei mir auch. Ich bin also neu im Bereich Gurken und versuche, die Struktur noch zu verstehen.

Da Sie auf die Zeile hingewiesen haben, die aktualisiert werden muss, können wir meiner Meinung nach einfach so etwas neben sourceLocation hinzufügen:

pickle: this.testCase.pickle

Dann kann jeder, der es im Hook konsumieren möchte, wie folgt darauf zugreifen:

testCase.pickle.tags
testCase.pickle.name
etc. 

Ich habe das Update gemacht, bin mir aber nicht 100% sicher, wie ich alle zugehörigen Tests aktualisieren soll. Könnten Sie eine Anleitung geben?

Ich konnte die Änderung testen, indem ich meinen Fork mit den Änderungen zu einem meiner lokalen Projekte verknüpfte. Das vollständige Testfallergebnis sieht wie folgt aus:

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

Nachdem ich einige weitere Tests durchgeführt hatte, bemerkte ich, dass pickle zu dem Zeitpunkt, an dem wir in test_case_runner Zugriff darauf haben, kein uri enthält. Daher denke ich, dass es in Ordnung ist, den Quellort so zu belassen, wie er ist.

PickleFilter gibt Pickle als Folgendes zurück:

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

Also wird alles die gleiche Minusgurke sein, die kein Ui enthält.

Eröffnet eine PR, um die bisherigen Änderungen hervorzuheben. Tests müssen noch aktualisiert werden.

Arbeiten an der Aktualisierung von Tests. Ich habe dieses Ding eingerichtet, um meine lokale Java-Version zu ändern, und habe festgestellt, dass ich einige der Funktionstests nicht ausführen konnte :/.

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.