Cucumber-js: Frage: Dokumentation der API-Nutzung

Dies scheint auch für https://github.com/webdriverio/wdio-cucumber-framework/issues/95 durchaus relevant zu sein

Keine mir bekannte Arbeit wurde in die Dokumentation der Verwendung der Javascript-API investiert. Einige der cli/runtime sind exponiert und relativ stabil.

Ich denke, wir könnten dies tun, indem wir die gewünschte API besprechen und dann, sobald wir eine Reihe von Anforderungen haben, die API anpassen und dokumentieren können. Ich vermute, wir brauchen etwas, das sich zwischen den CLI- und Runtime-Schnittstellen befindet.

Wollen Sie zum Übergeben einer benutzerdefinierten dynamischen Welt etwas anderes als das Festlegen des Weltkonstruktors?

Können Sie mehr Details zum dynamischen Laden von Features geben? Ist dies anders als die CLI aussieht.

Ich habe nur Erfahrung mit dem webdriver.io Gurkenadapter. Die Idee hier ist, die bereitgestellte WDIO-CLI als Hauptläufer zu verwenden, bei der Gurke über eine API über einen Framework-Adapter aufgerufen wird.

Ja, es gab Tage, an denen wir (in unserem Projekt) WDIO als Hauptweltinstanz verwendeten, an denen die Gurken-CLI der eigentliche Runner war. Aber da es diese Abstraktion von Framework-Adaptern in WDIO gibt, ist es sinnvoll, sie zu verwenden. Siehe auch andere Adapter: http://webdriver.io/guide/testrunner/frameworks.html

Ich versuche derzeit, die Klasse Runtime zu verwenden, um das wdio-cucumber-framework zu aktualisieren, um Gurke 4 zu unterstützen (derzeit ist es nur noch auf 2.3) ausgerichtet, und ich spüre irgendwie die Probleme mit der Gurken-API.

Ich frage mich zum Beispiel, warum es diesen EventDataCollector überhaupt gibt 😏. Z.B. Warum haben alle ausgegebenen Ereignisse keine Nutzlast mit dem vollständigen Kontext (GherkinDocument, currentScenario, currentStep)? Das würde einen solchen Sammler vielleicht überflüssig machen? Aber vielleicht übersehe ich hier etwas.

Ich wette, es gibt noch viele andere Ideen, Vorschläge und Anforderungen. Mal sehen, wohin das führt.

Dieses Problem tauchte für uns heute auch aufgrund der Integration mit anderen Läufern wieder auf.
Das Argument für eine API ist immer noch sehr gültig.
Irgendwelche Pläne dazu?

Auch darauf stoßen. Baue derzeit ein e2e-Testing-Framework auf. Ich würde gerne dieses Framework testen. Dazu hätte ich lieber API-Zugriff auf die Laufzeit. Einige Klassen werden verfügbar gemacht, obwohl sie weder dokumentiert noch in der Typescript-Definitionsdatei definiert sind. Dies hinterlässt bei mir den Eindruck, dass die Klassen, obwohl sie exponiert sind, nicht für die Produktion verwendet werden sollen.

Wenn jemand ein Update zu diesem Thema bereitstellen und meine Annahmen entweder bestätigen oder widerlegen könnte, wäre das großartig.