Hier sind drei Beispiel-BDD-Anweisungen, die helfen sollten, meine Frage zu erklären:
%Vor%vs
%Vor%Also ist das obige Szenario 1 in Ordnung, aber das ist das Beste aus Aussage 2 und 3. Aussage 2 liest schön und prägnanter. Aber meine Schrittdefinition für "Gegeben bin ich mit dem Benutzernamen" myUsername "und" myPassword "in das System eingeloggt" muss Aufrufe an die Page Objects (oder gleichwertig) wiederholen, dass das Szenario 1 aufgerufen wird ... scheint mehr Aufwand zu sein.
Also, ich frage mich wirklich, ob irgendjemand weiß, was die beste Praxis ist. Ich habe online gesucht und folgendes Dokument gefunden: Ссылка
Dieses Szenario 2 ist am besten, schreibt dann aber: "Einen Benutzer authentifizieren (Eine Ausnahme von der Empfehlung ohne Interaktion. Dinge, die" früher passierten "sind ok)", die sich für Szenario 3 eignet.
Prost,
Charlie
Hier ist meine Überprüfung der Szenarien, die Sie geschrieben haben.
Vorteile : Sie verwenden die Anweisungen Given, When und Then korrekt. In diesem Szenario legt das Given den Anfangszustand des Systems fest, das When gibt die Aktionen an, die ein Benutzer ausführen wird, und das Then gibt die Assertionen an, die zur Überprüfung des Verhaltens des Systems durchgeführt wurden.
Nachteile : Während das, was Sie geschrieben haben, funktionieren wird, besteht das Problem darin, dass dieser Test brüchig ist. Wenn Ihr Unternehmen ein zeitabhängiges Sicherheitstoken bei der Anmeldung festlegen müsste (zum Beispiel), müssten Sie einen weiteren Schritt hinzufügen, um dieses zusätzliche Feld einzugeben. Wenn Sie diesen Schritt jedoch neu schreiben, um deklarativ zu sein, z. B.
%Vor%Wenn der Anmeldevorgang geändert wurde, müssten Sie nur den Code ändern, das Szenario würde gleich bleiben.
Vorteile : Wie oben.
Nachteile : Auch hier ist der Test spröde, da Sie unbedingt die Anmeldedaten und ein bestimmtes Produkt angeben müssen. Ich würde dies wie folgt umschreiben:
%Vor%Sie können das im Schritt "Wenn" angegebene Produkt in ScenarioContext.Current speichern. Sie könnten dann diesen Wert in Ihrem "Dann" -Schritt erneut verwenden, um zu bestätigen, dass er im Produktinventar vorhanden ist.
Nachteile : Dies ist das schlimmste Szenario, wenn Sie die Anweisung "Given" falsch verwenden. Eine Given-Anweisung sollte verwendet werden, um einen initialen Systemstatus für den Test zu definieren, also in diesem Fall "Gegeben bin ich auf dem Anmeldebildschirm" ist eine korrekte Verwendung, aber "Gegeben, gebe ich den gültigen Benutzernamen" myUsername "" ist eine falsche Verwendung . Es ist inkorrekt, da es eine Benutzeraktion anzeigt, daher sollte es von einem Wann abgedeckt werden. Ja, Sie können ein Given verwenden, um die gleichen programmatischen Schritte wie ein When auszuführen, aber es macht es nicht richtig!
Ich würde dieses Szenario auf die Version ändern, die ich in Szenario 2 vorgeschlagen habe.
Erstens gibt es in Gherkin absolut nichts, was Sie daran hindert, Spezifikationen in beliebiger Reihenfolge zu schreiben. Sie können sogar Compound-Spezifikationen wie
erstellen %Vor%Warum sollten Sie das tun?
Nun lassen Sie uns zunächst eine vierte Variante Ihres Szenarios betrachten.
%Vor% Dies ist natürlich nur eine Verbindung von 1 und 2. Vielleicht haben Sie dies geschrieben, weil Sie mit dem Testen des Logins fertig waren und schnell ein Produkt kaufen und testen wollten. Sie haben bereits den Code für die Binding s in Szenario 1 und müssen jetzt einfach die Bindungen für Szenario zwei schreiben. Sie könnten dies als Ihre einfachste pragmatische Veränderung betrachten und Sie werden es später umgestalten. Damit ist nichts verkehrt, die Tests könnten schneller laufen, aber auch nicht gerade ideal.
Stellen Sie sich jetzt vor, dass Sie aufgrund der Art Ihres Shops viele Tests geschrieben haben, die verschiedene Kaufprozesse testen. Wir könnten testen, was passiert, wenn Sie den gleichen Artikel erneut in Ihren Warenkorb legen oder wenn Sie versuchen, etwas ausverkauft, oder verschiedene Checkout-Erfahrungen, wenn Sie eine spezielle Lieferung wünschen. In der Tat ist Ihr Geschäft so erfolgreich, dass Sie wirklich sicher im Web sein müssen und Ihren Login-Prozess ändern müssen. Leider haben Sie jetzt diese drei Zeilen
%Vor%wird in allen Szenarien wiederholt. Wenn wir versehentlich unseren Login-Prozess mit schlechtem Code unterbrechen, schlagen plötzlich alle unsere Tests fehl. Sie werden mit einer roten Wand konfrontiert und können nicht wirklich eingrenzen, wo Sie anfangen sollten, die Probleme zu betrachten. Da wir von der Anmeldung abhängig sind, bevor wir unser Szenario ausführen, können wir die Anmeldung beim Kauf nicht isolieren.
Das ist wirklich der Unterschied zwischen einem Given und einem When . A When gibt an, dass wir einen Prozess ausführen, Given ist ein Mittel, um die Laufzeitumgebung direkt zu beeinflussen, sodass wir einfach den richtigen Status haben. Es ist im Grunde der Unterschied zwischen
Das Given hat keine Möglichkeit zu scheitern.
Sie kommen also den ganzen Weg zurück zu Ihrer ursprünglichen Frage,
Können Sie Given s als When s wiederverwenden? Ja, aber auf lange Sicht wird es Sie verwirren.
Aber wenn Sie fragen Können Sie When s als Given s wiederverwenden? würde ich Ihnen definitiv empfehlen, das nicht zu tun. Das wird die Tatsache verbergen, dass etwas, das kaputt gehen könnte, getestet wird.
Schließlich gibt es eine andere Sache zu betrachten, und das ist die Domäne Ihrer Spezifikation. Dan North hat einen wirklich guten Artikel über diese Wessen Domain ist das überhaupt? , aber der allgemeine Kern, der hier auf Ihr Beispiel angewendet wird, ist, dass Sie, wenn Sie Produktkäufe betrachten, einfach
schreiben können %Vor%oder
%Vor%weil der Benutzername und das Passwort für die Anmeldung und nicht für Produkte verwendet werden. Auf diese Weise können Sie nicht alle Szenarien neu schreiben, wenn Sie Ihren Anmeldevorgang ändern, um etwas anderes zu verwenden.