Cucumber-js: вопрос: документация по использованию API

Кажется, это также актуально для https://github.com/webdriverio/wdio-cucumber-framework/issues/95

Никакая известная мне работа не была посвящена документированию того, как использовать javascript API. Некоторые из cli / runtime открыты и относительно стабильны.

Я предполагаю, что один из способов, которым мы могли бы это сделать, - это обсудить желаемый API, а затем, когда у нас будет набор требований, мы сможем преобразовать API в соответствии с ним и задокументировать его. Я предполагаю, что нам нужно что-то среднее между интерфейсами CLI и Runtime.

Вы хотите сказать, что для передачи настраиваемого динамического мира вам нужно что-то иное, чем установка конструктора мира?

Не могли бы вы подробнее рассказать о динамической загрузке функций. Это не так, как выглядит интерфейс командной строки?

У меня есть только опыт работы с адаптером огурца webdriver.io. Идея здесь состоит в том, чтобы использовать предоставленный WDIO CLI в качестве основного бегуна, где огурец вызывается через API через адаптер фреймворка.

Да, были дни, когда мы (в нашем проекте) использовали WDIO в качестве основного экземпляра мира, где CLI огурца был фактическим исполнителем. Но поскольку в WDIO есть эта абстракция адаптеров фреймворка, есть смысл их использовать. См. Также другие адаптеры: http://webdriver.io/guide/testrunner/frameworks.html

В настоящее время я пытаюсь использовать класс Runtime для обновления wdio-cucumber-framework для поддержки огурца 4 (в настоящее время он все еще нацелен только на 2.3), и я каким-то образом чувствую проблемы с API огурца.

Например, мне интересно, почему этот EventDataCollector вообще существует 😏. E. g. почему все сгенерированные события не имеют полезной нагрузки с полным контекстом (gherkinDocument, currentScenario, currentStep)? Это сделало бы такой коллекционер устаревшим? Но, возможно, я что-то здесь упускаю.

Бьюсь об заклад, есть много других идей, предложений и требований. Посмотрим, к чему это приведет.

Эта проблема снова возникла для нас сегодня также из-за интеграции с другими бегунами.
Аргументы в пользу наличия API по-прежнему актуальны.
Какие планы на это?

Тоже сталкиваюсь с этим. В настоящее время создается среда для тестирования e2e. Я бы хотел протестировать этот фреймворк. Для этого я бы предпочел иметь доступ к среде выполнения через API. Некоторые классы доступны, хотя они недокументированы и не определены в файле определений Typescript. Это оставляет у меня впечатление, что классы, даже если они открыты, не должны использоваться для производства.

Если бы кто-то мог предоставить обновленную информацию по этой проблеме и подтвердить или опровергнуть мои предположения, это было бы здорово.