Gherkin - Gegebene Anweisungen einfach als When-Anweisungen wiederverwenden ... akzeptabel?

Question

Hier sind drei Beispiel-BDD-Anweisungen, die zur Erklärung meiner Frage beitragen sollen:

Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page

Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

vs

Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory

Szenario 1 oben ist also in Ordnung, aber das Beste aus Aussage 2 und 3.Aussage 2 liest sich schöner und prägnanter.Aber meine Schrittdefinition für "Angesichts der Tatsache, dass ich mit dem Benutzernamen" myusername "und" mypassword "in das System angemeldet bin, muss Anrufe zu den Seitenobjekten (oder dem gleichwertigen) wiederholen, die Szenario 1 namens ...Scheint mehr Entwicklungsaufwand zu sein.

Ich frage mich also wirklich, ob jemand weiß, welches die beste Vorgehensweise ist.Ich habe online gesucht und das folgende Dokument gefunden:http://docs.behat.org/guides/1.gherkin.html

Dieses Vorschlagsszenario 2 ist am besten, schreibt dann aber:„Authentifizierung eines Benutzers (Eine Ausnahme von der Empfehlung, keine Interaktion durchzuführen.Dinge, die „früher passiert sind, sind in Ordnung)“, was sich irgendwie für Szenario 3 eignet.

Prost,

Charlie

Answer 1

Hier ist meine Bewertung der Szenarien, die Sie geschrieben haben.

Szenario 1

generasacodicetagpre.

Profis : Sie verwenden die angegebenen, wann und dann Aussagen korrekt. In diesem Szenario legt der angegebene Set den Anfangszustand des Systems, wann die Aktionen angibt, die ein Benutzer annimmt, und dabei die Angaben der Angaben die Geltendmachung, um das Verhalten des Systems zu überprüfen.

cons : Während Sie, was Sie geschrieben haben, funktioniert, ist das Problem, das Sie haben, ist, dass dieser Test brüchig ist. Wenn Ihr Unternehmen angemeldet wurde, dass ein zeitabhängiges Sicherheitstoken auch während des Anmeldes angegeben werden musste (z. B.), müssen Sie einen weiteren Schritt hinzufügen, um dieses zusätzliche Feld einzugeben. Wenn Sie jedoch diesen Schritt wieder einschätzen, um deklarativen, z. B.

generasacodicetagpre.

Wenn dann der Anmeldeprozess geändert wurde, müssen Sie den Code nur ändern, das Szenario bleibt gleich.

Szenario 2

generasacodicetagpre.

Profis : Gleich wie oben.

cons : Wieder ist der Test brüchig, da es unerlässlich ist, d. H. Sie geben die genauen Anmeldeanmeldeinformationen und ein bestimmtes Produkt an. Ich würde dies wiederschreiben als:

generasacodicetagpre.

Sie können das in der "wann" angegebene Produkt speichern, das in szenariocontext.current < / a>. Sie würden dann in der Lage sein, diesen Wert in Ihrem "dann" -Schritt wiederzunehmen, um zu behaupten, dass er im Produktbestand vorhanden ist.

Szenario 3

generasacodicetagpre.

cons : Dies ist das schlechteste Ihrer Szenarien, wie Sie die gegebene Anweisung falsch verwenden. Eine bestimmte Anweisung sollte verwendet werden, um einen anfänglichen Systemstatus für den Test zu definieren. In diesem Fall ist in diesem Fall "angesichts i am Anmeldebildschirm" eine korrekte Verwendung, aber "angesichts i betritt ich den gültigen Benutzernamen" MyUsName "" ist eine falsche Verwendung . Es ist falsch, da er eine Benutzeraktion angibt, daher sollte es von einem wann abgedeckt werden. Ja, Sie können ein gegebenes, um dieselben programmatischen Schritte als wann auszuführen, aber es macht es nicht richtig!

Ich würde dieses Szenario in die in Szenario 2 vorgeschlagene Version ändern.

Answer 2

Erstens gibt es in Gherkin absolut nichts, was Sie daran hindert, Spezifikationen in beliebiger Reihenfolge zu schreiben. Sie können sogar zusammengesetzte Spezifikationen erstellen, z

Given ...
When... 
Then ...
When ...
Then ...
Given ...
When ... 
Then ...

Warum sollten Sie das also tun?

Betrachten wir zunächst eine vierte Variante Ihres Szenarios

Scenario: User logs in and buys a product
  Given I am on the login screen
  When I enter the valid username "myUsername"
  And I enter the valid password "myPassword"
  And I press the login button
  Then I should see the login successful page
  When I purchase the product "myProduct"
  Then I should have "myProduct" in the product inventory

Dies ist natürlich nur eine Verbindung von 1 und 2.Möglicherweise haben Sie dies geschrieben, weil Sie mit dem Testen der Anmeldung fertig waren und schnell etwas schreiben und den Kauf eines Produkts testen wollten.Sie haben bereits den Code dafür Bindings in Szenario eins und müssen jetzt nur noch die Bindungen für Szenario zwei schreiben.Sie könnten dies als Ihre einfachste pragmatische Änderung betrachten und sie später umgestalten.Daran ist nichts auszusetzen, die Durchführung der Tests könnte schneller gehen, aber es ist auch nicht gerade ideal.

Stellen Sie sich nun vor, dass Sie aufgrund der Beschaffenheit Ihres Shops viele Tests geschrieben haben, die unterschiedliche Kaufprozesse testen.Wir könnten testen, was passiert, wenn Sie denselben Artikel erneut in Ihren Warenkorb legen, oder wenn Sie versuchen, etwas zu kaufen, das nicht vorrätig ist, oder unterschiedliche Checkout-Erfahrungen, wenn Sie eine Sonderlieferung wünschen.Tatsächlich ist Ihr Shop so erfolgreich, dass Sie im Web wirklich sicher sein und Ihren Login-Prozess ändern müssen.Leider haben Sie jetzt diese drei Zeilen

Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"

wiederholt sich in Ihren Szenarien.Wenn wir versehentlich unseren Anmeldevorgang mit einem fehlerhaften Code unterbrechen, schlagen plötzlich alle unsere Tests fehl.Sie stehen vor einer roten Wand und können nicht wirklich eingrenzen, wo Sie mit der Betrachtung der Probleme beginnen sollen.Da wir uns vor der Ausführung unseres Szenarios anmelden müssen, können wir die Anmeldung nicht vom Kauf trennen.

Das ist wirklich der Unterschied zwischen a Given und ein When.A When Gibt es einen Hinweis darauf, dass wir einen Prozess durchführen, a Given ist eine Möglichkeit, die Laufzeitumgebung direkt zu beeinflussen, sodass wir einfach den richtigen Status haben.Es ist im Grunde der Unterschied zwischen

//Given
isLoggedIn = true

//When
if CheckValidPasswordForUser(user, password)
   isLoggedIn = true

Der Given hat keine Möglichkeit zu scheitern.

Um noch einmal auf Ihre ursprüngliche Frage zurückzukommen:

Können Sie wiederverwenden? Givens wie WhenS? Ja, aber auf lange Sicht wird es Sie verwirren.

Aber wenn Sie fragen Können Sie wiederverwenden? Whens wie GivenS? dann würde ich dir auf jeden Fall davon abraten.Dadurch wird die Tatsache verschleiert, dass etwas getestet wird, das kaputt gehen könnte.

Schließlich gibt es noch eine weitere Sache, die Sie berücksichtigen sollten, nämlich den Bereich Ihrer Spezifikation.Dan North hat einen wirklich guten Artikel dazu Wessen Domain ist es überhaupt?, aber der allgemeine Kern, der auf Ihr Beispiel hier angewendet wird, ist, dass Sie beim Kauf eines Produkts einfach schreiben können

Given I am logged in as a customer

oder

Given I am logged in as an administrator

Denn die Teile „Benutzername“ und „Passwort“ beziehen sich auf die Anmeldung und nicht auf Produkte. Auf diese Weise sind Sie davor geschützt, alle Ihre Szenarien neu zu schreiben, wenn Sie Ihren Anmeldevorgang ändern, um etwas anderes zu verwenden.