Ist es möglich, abhängig von der aktuellen Umgebung mit Behat unterschiedliche Schrittdaten zu verwenden?

Question

Ich renne in ein bisschen ein Rätsel. Wir haben ein antiquiertes System, für das ich schreibe, für das Behat testet. Es funktioniert größtenteils gut. Aber ich habe ein Problem festgestellt, bei dem die Behat-Tests fehlschlagen, wenn die Daten, die ich für die aktuelle Umgebung testet, für eine andere Umgebung bestimmt sind.

Zum Beispiel, wenn ich eine Suche per Telefonfunktion in QA und erwarten, dass es eine bestimmte Entity-ID zurückgeben kann ich nicht die gleiche Telefonnummer und Entity-ID in RC oder Live zu testen. Daher möchte ich, dass die Testdaten für jede Umgebung in Behat übersichtlich verwaltet werden können.

Ein paar Gedanken wurden hier herumgeschleudert, wie das Einfügen der Daten in das Profil (höchst unerwünscht) oder das Erstellen von CSV-Dateien für jede Funktion. Ich denke auch darüber nach, alle datenspezifischen Szenarien mithilfe von Tabellen oder Szenariokonturen zu erstellen und eine Umgebungsspalte zu verwenden, die verwendet wird, um die aktuelle Umgebung zu überprüfen und zu überspringen, wenn die Zeile nicht für die aktuelle Umgebung bestimmt ist. Vielleicht mit einem Hintergrund oder einem anderen Haken, um damit zu helfen.

Kennt jemand einen guten Weg oder Best Practice für den Umgang mit mehreren Umgebungen mit verschiedenen Datensätzen in jedem mit Behat?

Answer 1

Laut den Leuten von KNP Labs während eines ihrer Trainings, ist es die beste Praxis, die notwendigen Daten für ein Szenario zu schaffen, um als Teil des Gegebenen oder Hintergrundes erfolgreich zu sein 7 Telefonnummern "und die Schrittdefinition fügt sieben Telefonnummern ein, auf die man sich für den Rest dieses Szenarios verlassen kann.

Natürlich ist das oft nicht machbar, wenn Sie Tests gegen eine Produktionsstätte durchführen wollen, und die Strategien, die ich gesehen habe, variieren je nach Menge der spezifischen Daten und wie volatil die Daten in der Produktion sind.

Da Best Practices außerdem vorschreiben, dass die Feature-Dateien das Anwendungsverhalten im Hinblick auf den zu erwartenden Funktionsberechtigten beschreiben sollen, ist es unwahrscheinlich, dass das Ausstellen umweltbedingter Daten in der Feature-Datei einen optimalen Ansatz darstellt. Der Zielfunktionsbenutzer ist sich der unterschiedlichen Umgebungen wahrscheinlich nicht bewusst.

Wenn die Produktionsdaten stabil genug sind, um Tests zu schreiben, würde ich in Erwägung ziehen, einen Parameter oder ein Profil in behat.yml festzulegen, mit dem die Umgebung zur Laufzeit angegeben und eine benutzerdefinierte Schrittdefinition geschrieben werden kann. Die benutzerdefinierte Schrittdefinition könnte bekannte Produktionswerte in einem Fall liefern und diese Werte in die anderen einfügen. Und die Gherkin würde immer noch aussehen wie "Vorgegeben, dass ich 7 Telefonnummern habe", so dass sich die Funktion auf den Geschäftswert und den Nutzen für den Benutzer und nicht die Testumgebung konzentrieren würde.