Cucumber-js: question : documentation de l'utilisation de l'API

Cela semble être également tout à fait pertinent pour https://github.com/webdriverio/wdio-cucumber-framework/issues/95

À ma connaissance, aucun travail n'a été consacré à la documentation de l'utilisation de l'API javascript. Certains des cli/runtime sont exposés et relativement stables.

Je suppose qu'une façon de procéder est de discuter de l'API souhaitée, puis une fois que nous avons un ensemble d'exigences, nous pouvons transformer l'API pour l'adapter et la documenter. Je suppose que nous avons besoin de quelque chose qui se situe entre les interfaces CLI et Runtime.

Pour passer un monde dynamique personnalisé, dites-vous que vous voulez quelque chose de différent que de définir le constructeur de monde ?

Pouvez-vous donner plus de détails sur le chargement dynamique des fonctionnalités. Est-ce d'une manière différente de ce à quoi ressemble la CLI.

Je n'ai d'expérience qu'avec l'adaptateur de concombre webdriver.io. L'idée ici est d'utiliser la CLI WDIO fournie comme coureur principal où le concombre est appelé via une API via un adaptateur de framework.

Oui, il y a eu des jours où nous (dans notre projet) utilisions WDIO comme instance mondiale principale où la CLI de concombre était le véritable coureur. Mais comme il existe cette abstraction d'adaptateur de framework disponible dans WDIO, il est logique de les utiliser. Voir aussi d'autres adaptateurs : http://webdriver.io/guide/testrunner/frameworks.html

J'essaie actuellement d'utiliser la classe Runtime pour mettre à jour wdio-cucumber-framework afin de prendre en charge le concombre 4 (actuellement, il ne cible toujours que 2.3) et je ressens en quelque sorte les problèmes avec l'API concombre.

Par exemple, je me demande pourquoi cet EventDataCollector existe . Par exemple. pourquoi tous les événements qui ont été émis n'ont-ils pas de charge utile avec le contexte complet (gherkinDocument, currentScenario, currentStep) ? Cela rendrait un tel collectionneur peut-être obsolète ? Mais peut-être que j'ai raté quelque chose ici.

Je parie qu'il y a beaucoup d'autres idées, suggestions et exigences. Voyons où cela va.

Ce problème est réapparu pour nous aujourd'hui également en raison de l'intégration avec d'autres coureurs.
Les arguments en faveur d'une API sont toujours très valables.
Des plans dessus ?

Rencontrer cela aussi. En cours de construction d'un cadre de test e2e. J'aimerais tester ce framework. Pour ce faire, je préférerais avoir un accès API au runtime. Certaines classes sont exposées bien qu'elles ne soient pas documentées ni définies dans le fichier de définitions Typescript. Cela me laisse l'impression que les classes, même si elles sont exposées, ne doivent pas être utilisées pour la production.

Si quelqu'un pouvait fournir une mise à jour sur ce problème et pouvait soit confirmer ou réfuter mes hypothèses, ce serait génial.