2017-05-08 2 views
1

Ich arbeite an einer Reihe von Gurken-Tests, deren Testtabelle das Potential hat, stark zu wachsen. Beispiel unten mit diesem Formular:Gurken Testtabellen wachsen zu lange

Ich meine, mit diesem einfachen Login hat die Datentabelle drei Parameter. Aber wenn ich anfange, Formulare auszufüllen, kann die Datentabelle leicht auf dreißig, vierzig Parameter anwachsen.

Ich habe überlegt, den Testfall wie unten beschrieben neu zu schreiben. Auf diese Weise gibt es höchstens zwei Parameter in der Testtabelle: den Testfallnamen und die Benutzer-E-Mail, die wie ein Primärschlüssel sind.

Anschließend werden Daten aus einer Tabelle mit diesen beiden Parametern abgerufen, um eine HashMap auszufüllen, auf die der Rest des Testfalls zugreift.

Feature: Login Action with a Named User 

Scenario Outline: Succesful first login with valid credentials 
Given User is on Foo LoginPage 
# And User has recently registered 
When User logs into app with "<user>" 
Then I validate user information appears in profile name 
    And Mi perfil icon is displayed 

Examples: 
    |TC_NAME |user  | 
    |TC01 |[email protected]| 
    |TC02 |[email protected]| 

Kalkulationstabelle sieht wie folgt aus:

Data Pool spreadsheet

Irgendwelche Gedanken? Haben Sie etwas anderes verwendet, um eine lange Datentabelle in Ihren Cucumber-Definitionen zu vermeiden?

Antwort

1

Basierend auf Kyles Antwort, grub ich in Cucumber Dokumentation, die mich dazu gebracht, für jeden Schritt Inline-Rohr Tabellen zu verwenden, statt im Abschnitt Beispiele vierzig Spalten, wie folgt aus:

... 
Scenario Outline: Compose an email in Gmail 
Given I am logged onto gmail with: 
|user | pwd | 
|foo | bar | 
When I click the compose button 
And enter user email, subject and message as: 
    |to | subject | message | 
    |fuu | subj | ...  | 
... 

Man kann sehen, Wie, wenn viel mehr Felder eingegeben werden, werden Daten handhabbar. Plus, es gibt ein nettes Tool namens Tidy Gherkin, das Rohrtabellen ausrichten kann, das ist also ein Bonus.

0

Wenn Sie eine lange Liste von Parametern in Ihren Szenariotabellen haben, machen Sie höchstwahrscheinlich etwas falsch.

Gurke ist ein Werkzeug für Gespräche, und weniger über die Tests im Hintergrund. Es geht darum, ein Anforderungsdokument zu haben, das ausgeführt werden kann. Wenn niemand die Dokumentation verstehen kann (was mit der Menge an Scrollrechten recht schwierig wäre würde 40 Spalten erfordern), ist es falsch geschrieben worden.

Es würde entweder mehr Szenarien verwenden, anstatt eine massiv komplexe Tabelle zu schreiben, oder das von Ihnen geschriebene Szenario verkürzen (was normalerweise der bessere Weg zum Arbeiten ist).

Programmatisch sind Excel-Sheets, Switch-Anweisungen und Objekte großartige Möglichkeiten, um Testdaten zusammen mit verschiedenen Switches zu sammeln. Verwenden Sie diese stattdessen und es sieht nicht nur sauberer aus, es wird auch verständlicher.