Ich erstelle eine Szenario-Gliederung ähnlich der folgenden (es ist eine vereinfachte Version, gibt aber einen guten Hinweis auf mein Problem):
%Vor%Die Beispieltabelle enthält die Testdaten, die ich benötige, aber ich würde eine weitere Beispieltabelle mit nur den Namen der Operatoren (anstelle von MyOperatorName) hinzufügen, um die Tests für verschiedene Operatoren zu replizieren
%Vor%um zu vermeiden, dass das gleiche Szenario dreimal wiederholt wird; 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 dieselben 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.
Ich bin froh, dass Sie wissen, dass das nicht möglich ist ... Welche Möglichkeiten gibt es? Scheint so, als gäbe es 5:
a: Erstellen Sie eine Tabelle mit jeder Option (das Kreuzprodukt)
%Vor%b. Wiederholen Sie das Szenario für jeden Operator mit einer Tabelle mit Eingabezeilen - Aber du hast gesagt, du wolltest das nicht tun.
c. Wiederholen Sie das Szenario für jede Eingabezeile mit einer Tabelle mit Operatoren - Ich mag diese Option, weil jede Regel ein separater Test ist. Wenn Sie wirklich wirklich sicherstellen möchten, dass jede unterschiedliche Implementierung Ihrer "Operator" -Strategie in den gleichen Validierungsszenarien besteht und scheitert, dann schreiben Sie jedes Validierungsszenario als eine einzelne Szenario-Gliederung: z. B.
%Vor%d. Überdenken Sie, wie Sie Specflow verwenden - wenn Sie nur KEY-Beispiele benötigen, um Ihre Funktionen 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 geeignet sein ... aber Sie sollten 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 gleich ist, testen Sie sie einmal und lassen Sie dann alle Operatoren von der gleichen Validatorklasse übernehmen oder in ihre Komposition aufnehmen.