Mehrdimensionale Szenario Outlines in Specflow

Question

Ich bin ein Szenario zu schaffen, um den folgenden ähnliche Kontur (es eine vereinfachte Version ist gibt aber einen guten Hinweis auf meinem Problem):

Given I have a valid operator such as 'MyOperatorName' 
    When I provide a valid phone number for the operator 
    And I provide an '<amount>' that is of the following '<type>' 
    And I send a request 
    Then the following validation message will be displayed: 'The Format of Amount is not valid' 
    And the following Status Code will be received: 'AmountFormatIsInvalid' 

Examples: 
    | type  | description      | amount | 
    | Negative | An amount that is negative  | -1.0 | 
    | Zero  | An amount that is equal to zero | 0  | 
    | ......... | ..........      | .... | 

Die Beispiele Tabelle gibt den Test Daten, die ich brauche, aber ich würde das gleiche Szenario zu wiederholen Umriss dreimal andere Beispiele Tabelle mit nur den Namen der Operatoren (statt MyOperatorName), um die Tests für verschiedene Betreiber

Examples: 
    | operator | 
    | op_numb_1 | 
    | op_numb_2 | 
    | op_numb_3 | 

, um zu replizieren zu vermeiden hinzufügen ; Ich weiß, dass dies nicht möglich ist, aber ich frage mich, was der beste Ansatz ist, um zu vermeiden, dass innerhalb des Features drei verschiedene Szenariokonturen verwendet werden, die abgesehen vom Namen des Operators ziemlich gleich sind. Ich weiß, dass ich die gleichen Schrittdefinitionen wiederverwenden kann, aber ich versuche zu verstehen, ob es eine Best Practice gibt, um zu verhindern, dass das Feature mit zu ähnlichen Szenarien überflutet wird.

Answer 1

Gut, dass Sie wissen, dass das nicht möglich ist ... Also welche Möglichkeiten gibt es? Scheint, wie es 5 sind:

a: Erstellen Sie eine Tabelle mit jeder Option (Kreuzprodukt)

Examples: 

| type  | description      | amount | operator | 
| Negative | An amount that is negative  | -1.0 | op_numb_1 | 
| Zero  | An amount that is equal to zero | 0  | op_numb_1 | 
| Negative | An amount that is negative  | -1.0 | op_numb_2 | 
| Zero  | An amount that is equal to zero | 0  | op_numb_2 | 
| ......... | ..........      | .... | ...  | 

b. Wiederholen Sie das Szenario für jeden Operator mit einer Tabelle der Eingabezeilen - aber Sie sagten, Sie wollten dies nicht tun.

c. Wiederholen Sie das Szenario für jede Eingabezeile, mit einer Tabelle von Operatoren - Ich mag diese Option, denn jede Regel ist ein separater Test. Wenn Sie wirklich, wirklich sicherstellen möchten, dass jede unterschiedliche Implementierung Ihrer "Operator" -Strategie in den gleichen Validierungsszenarien besteht und versagt, dann warum schreiben Sie nicht jedes Validierungsszenario als eine einzelne Szenario-Gliederung: z.

Scenario Outline: Operators should fail on Negative inputs 
Given I have a valid operator such as 'MyOperatorName' 
When I provide a valid phone number for the operator 
And I send a request with the amount "-1.0" 
Then the following validation message will be displayed: 'The Format of Amount is not valid' 
And the following Status Code will be received: 'AmountFormatIsInvalid' 

Scenario Outline: Operators should fail on Zero inputs 
...etc... 

d. Überdenken Sie, wie Sie Specflow verwenden - wenn Sie nur KEY-Beispiele benötigen, um Ihre Features zu illustrieren (wie in Beispiel von Gojko Adzic beschrieben), dann übertreiben Sie es, indem Sie jede Kombination prüfen. Wenn Sie jedoch specflow verwenden, um Ihre vollständige Suite von Integrationstests zu automatisieren, dann könnten Ihre Szenarien angemessen sein ... aber Sie möchten vielleicht über e nachdenken.

e. Schreiben Sie Integrations-/Komponententests basierend auf der Idee, dass Ihre "Operator" -Validierungslogik nur an einer Stelle angewendet wird. Wenn die Validierung für jeden Operator identisch ist, warum testen Sie sie nicht einmal und lassen Sie dann alle Operatoren von der gleichen Validatorklasse übernehmen oder in ihre Komposition aufnehmen.