Sollten BDD-Szenarien tatsächliche Testdaten enthalten oder einfach beschreiben?

Question

Wir haben einen Punkt erreicht, wo wir haben erkannt, dass es zwei Optionen für die Testdaten angeben, wenn ein typisches CRUD Szenario definieren:

Option 1: Die Daten zu verwenden Beschreiben Sie, und lassen Sie die Umsetzung der Definition Daten

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have typed in a valid name 
     And I have typed in a valid code 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the created region details 

Option 2: explizit der Testdatenzustand

Scenario: Create a region 
    Given I have navigated to the "Create Region" page 
     And I have filled out the form as follows 
     | Label | Value | 
     | Name | Europe | 
     | Code | EUR | 
    When I click the "Save" button 
    Then I should be on the "Regions" page 
    And the page should show the following fields 
     | Name | Code | 
     | Europe | EUR | 

In Bezug auf der bene zu verwenden passt und Nachteile, was wir festgestellt haben, ist, dass:

Option 1 deckt schön den Fall, wenn die Definition von sagen ein "gültiger Name" ändert. Dies könnte schwieriger sein, wenn wir mit Option 2 gehen würden, wo die Testdaten an mehreren Stellen sind. Option 1 beschreibt explizit, was bei den Daten für diesen Test wichtig ist, insbesondere wenn es sich um ein Szenario handelt, in dem wir etwas wie "hat eine ungültige Kreditkartennummer eingegeben" gesagt haben. Es fühlt sich auch irgendwie abstrakter und BDD an, da es sich mehr um eine Beschreibung als um eine Implementierung handelt.

Option 1 verwendet jedoch sehr spezifische Schritte, die nur schwer wiederverwendet werden können. Zum Beispiel "Die Seite sollte die erzeugten Regionsdetails anzeigen" wird wahrscheinlich nur von diesem Szenario verwendet. Umgekehrt könnten wir die Option 2 "Die Seite sollte die folgenden Felder anzeigen" so implementieren, dass sie in anderen Szenarien viele Male wiederverwendet werden kann.

Ich denke auch Option 2 scheint kundenfreundlicher, da sie durch Beispiel sehen können, was passiert, anstatt abstrakter Begriffe wie "gültig" zu interpretieren. Wäre Option 2 jedoch spröder? Das Refactoring des Modells könnte bedeuten, diese Tests zu unterbrechen, während, wenn die Testdaten im Code definiert sind, der Compiler uns bei Modelländerungen helfen wird.

Ich weiß es zu schätzen, dass es hier keine richtige oder falsche Antwort geben wird, aber ich würde gerne die Meinung der Leute hören, wie sie entscheiden würden, was sie verwenden sollen.

Danke!

Answer 1

Ich würde sagen, es kommt darauf an. Es gibt Situationen, in denen ein Szenario möglicherweise eine große Datenmenge erfordert, um eine erfolgreiche Ausführung abzuschließen. Oft ist die Mehrheit dieser Daten für das, was wir gerade testen, nicht wichtig und wird daher zu Lärm, der von dem Verständnis, das wir mit dem Szenario erreichen wollen, ablenkt.Ich habe damit begonnen, etwas zu verwenden, das ich ein Standarddatenmuster nenne, um Standarddaten bereitzustellen, die mit für das Szenario spezifischen Daten zusammengeführt werden können. Ich habe hier schon darüber geschrieben:

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

Ich hoffe, das hilft.

Answer 2

Ich ziehe Option 2.

Um den Business-Anwender sofort klar ist, was die Eingänge und die Ausgänge. Mit Option 1 wissen wir nicht, welche Daten gültig sind, daher ist Ihre Implementierung möglicherweise falsch.

können Sie noch ausdrucks sein durch zu ungültigen Daten hinzufügen, wenn entsprechende

Scenario: Filter for Awesome 
    Given I have navigated to the "Show People" page 
    And I have the following data 
    | Name | Value | 
    | John | Awesome| 
    | Bob | OK  | 
    | Jane | Fail | 
When I click the "Filter" button 
Then the list should display  
    | Name | Value | 
    | John | Awesome | 

Sie jedoch die Daten behalten sollte, so dass ihr in Bezug auf die Domain beschrieben, sondern dass die konkrete Umsetzung. Dies ermöglicht Ihnen, auf verschiedenen Ebenen in Ihrer Anwendung zu testen. z.B. UI Service usw.

Answer 3

Jedes Mal wenn ich darüber nachdenke ändere ich meine Meinung. Aber wenn Sie darüber nachdenken - der Test soll beweisen, dass Sie eine Region erstellen können. Ein Kriterium erfüllt beide Optionen. Aber ich stimme zu, dass die visuellen Hinweise mit Option 2 und Entwicklerfreundlichkeit wahrscheinlich zu gut sind, um sie abzulehnen. In solchen Beispielen zumindest.