Cucumber-js: 提案：cucumber-jsを実行するためのプログラムAPI

初期フィードバックのページング： @aslakhellesoy @charlierudolph @ aurelien- reeves @mattwynne @nicojs @ jan-molak

私はこの提案が大好きです！ 偽のキュウリのrunCucumberにはすでにこのようなAPIがあります

@ davidjgoss-素晴らしいですね！

参考までに、Serenity / JSが現時点でCucumberを呼び出す方法は次のとおりです- CucumberCLIAdapter
そして、これが構成パラメーターをargvに変換するロジックです- CucumberOptions 。

argvの代わりにオプションオブジェクトを提供できる方がはるかに良いでしょう👍🏻

大好きです！

その新しいパブリックAPIを指定する一方で、問題＃1489で最近何が起こったのかを検討し、パブリックAPIを提供して、フィルターとテスト中の結果の機能との相互作用をより良くすることを検討することもできます。

それに加えて、Cucumber-Electronにとっても簡単になるようなものを作りましょう。

• https://github.com/cucumber/cucumber-electron/blob/1c2faaa77065754d1ca17dce27fff1c421d226d0/src/renderer/main.js#L49
• https://github.com/cucumber/cucumber-electron/blob/0617ab15545ac5ceb4587599e589fefd0b670142/src/renderer/index.js#L41 -L50

パブリックAPIを使用する方が、何もないよりも優れているので、先に進んでください👍！

できれば、 cucumber-jsと同じルールを使用してプロファイルをロードするAPIもあるので、通常のcucumber-js呼び出しの正確な動作を模倣できます。

loadProfiles(directory = process.cwd()): Record<string, Profile>

StrykerJSは、 custom_formatters APIとeventBroadcasterによって公開されたイベントにも大きく依存します。 それらをパブリックAPIにも追加できますか？ 参照： https ：

できれば、cucumber-jsと同じルールを使用してプロファイルをロードするAPIもあるので、通常のcucumber-js呼び出しの正確な動作を模倣できます。

これは良い点です。 プロファイル（少なくとも現在の形式では）は基本的にCLIに結合されているため、プロファイルを境界のその側に保持するのは正しいと感じますが、プロファイルをロードして部分的なオプションオブジェクトを生成する関数を公開することもできます。

その新しいパブリックAPIを指定する際に、問題＃1489で最近何が起こったのかを検討し、テスト中のフィルターと結果の機能との相互作用をより良くするためにパブリックAPIを提供することを検討することもできます。

APIを呼び出すときにカスタムピクルスフィルターを提供するオプションを含めることができると思います（組み込みのフィルターを駆動する名前、タグなどに加えて）。

非常にコマンドライン-yの場合のプロファイルの現在の構文。

JSON、JavaScript、YAML、環境変数など、より一般的な形式でプロファイルを指定できるようにするには、❤️❤️❤️と思います。 JSONでは、次のようになります。

.cucumber.json

{
  "default": {
    "requireModule": ["ts-node/register"],
    "require": ["support/**/*./ts"],
    "worldParameters": {
      "appUrl": "http://localhost:3000/",
    },
    "format": ["progress-bar", "html:./cucumber-report.html"]
  },
  "ci": {
    "requireModule": ["ts-node/register"],
    "require": ["support/**/*./ts"],
    "worldParameters": {
      "appUrl": "http://localhost:3000/",
    },
    "format": ["html:./cucumber-report.html"],
    "publish": true
  }
}

または、JavaScriptを使用する

.cucumber.js

const common = {
  "requireModule": ["ts-node/register"],
  "require": ["support/**/*./ts"],
  "worldParameters": {
    "appUrl": "http://localhost:3000/",
  }
}

module.exports = {
  default: {
    ...common,
    "format": ["progress-bar", "html:./cucumber-report.html"]
  },
  ci: {
    ...common,
    "format": ["html:./cucumber-report.html"],
    "publish": true
  }
}

または、環境変数（たとえば、dotenvなどのツールを使用してロードされたもの）を使用した場合でも、次のようになります。

.cucumber.env

CUCUMBER_PROFILE_DEFAULT_REQUIREMODULE=ts-node/register
CUCUMBER_PROFILE_DEFAULT_REQUIRE=ts-node/register
CUCUMBER_PROFILE_DEFAULT_WORLDPARAMETERS_APPURL=http://localhost:3000/
CUCUMBER_PROFILE_DEFAULT_FORMAT=progress-bar,html:./cucumber-report.html
CUCUMBER_PROFILE_CI_REQUIREMODULE=ts-node/register
CUCUMBER_PROFILE_CI_REQUIRE=ts-node/register
CUCUMBER_PROFILE_CI_WORLDPARAMETERS_APPURL=http://localhost:3000/
CUCUMBER_PROFILE_CI_FORMAT=progress-bar,html:./cucumber-report.html
CUCUMBER_PROFILE_CI_PUBLISH=true

実際には、コンフィギュレーションライブラリーは、まさにこれを行います。 他のものが邪魔になったため、Cucumber-JVMに統合することは決してありませんでしたが、JavaScriptの実装で試してみることができるでしょうか？

@aslakhellesoyはそれが素晴らしいだろうと同意します！ この提案にPOCを導入して、もう少し具体的に話し合うことができるようにします。その一環としてプロファイルを作成したいと思います（4。5年、＃751を頼りに😄）

参照。 ＃1004

これは良い点です。 プロファイル（少なくとも現在の形式では）は基本的にCLIに結合されているため、プロファイルを境界のその側に保持するのは正しいと感じますが、プロファイルをロードして部分的なオプションオブジェクトを生成する関数を公開することもできます。

はい、プラグイン作成者の観点からすれば、それは素晴らしいことであり、非常にありがたいことです。

JSON、JavaScript、YAML、環境変数など、より一般的な形式でプロファイルを指定できるようにするには、❤️❤️❤️と思います。 JSONでは、次のようになります。

それはいいです！ また、cucumberJSと同じ方法でAPIをロードしていただければ幸いです。 単一のcucumber.jsファイルをロードするのは簡単です。 優先順位、ファイル形式などを含む構成ファイルの読み込みアルゴリズムを複製し、それを維持することはまったく別のことです😅。

Q：必要なキャッシュをクリアせずにrunCucumber 2回続けて実行できますか？ これは、ミューテーションテストのユースケースにとって重要です。

アクティブなミュータントを切り替えるために、グローバル変数を変更しながら、環境をロードし、テストをすばやく連続して複数回実行したいと考えています。

現在、 cliプライベートAPIを使用しており、各テスト実行の間にrequire.cacheからステップ定義ファイルをクリアする必要があります。 これはCommonJSには理想的ではなく、esmではまったく機能しません。

ユースケースの擬似コード：

const profiles = await loadProfiles();
const options = {
  ...profiles.default,
  formatter: require.resolve('./our-awesomely-crafted-formatter'),
  some: 'other options we want to override',
}
const cucumber = new Cucumber(options);

// Allow cucumber to load the step definitions once. 
// This is `async`, so support for esm can be added without a breaking change
await cucumber.initialize();

// Initial test run ("dry run"), without mutants active
await cucumber.run();

collectMutantCoveragePerTestFromFormatter();

// Start mutation testing:

global.activeMutant = 1;
await cucumber.run({ features: ['features/a.feature:24']);
collectResultsFromFormatterToDetermineKilledOrSurvivedMutant()

global.activeMutant = 2;
await cucumber.run({ features: ['features/b.feature:24:25:26', 'features/c.feature:12']);
collectResultsFromFormatterToDetermineKilledOrSurvivedMutant()

// etc

@nicojsは間違いなくこれが必要であることに同意します。たとえば、ラムダでキュウリを実行したい人が数回登場します。また、これも必要になるインタラクティブモードを追加したいと思います。

私がこれまでにスケッチしたのは、より機能的なスタイルでしたが、私が思うのと同じ基本的な概念でした。

const runnerOptions = {
    support: {
        require: ['features/support/**/*.js']
    }
}

// initial run returns support code library
const { support } = await runCucumber(runnerOptions)

// subsequent run reuses support code library
await runCucumber({
    ...runnerOptions,
    support
})

それは私たちのために働きます👍

私たちにも役立ちます👍🏻

このようなものは、テストツールの統合（Jest、Cypress）で今日発生している大きな混乱の代替手段として非常に役立つと思います。たとえば、これらの問題を（重要度の高い順に）見つけました。

• cypress-cucumber-preprocessorは、例のタグをサポートしていません（https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/196）
• jest-cucumberはCucumber JSONレポートをサポートしていません（https://github.com/bencompton/jest-cucumber/issues/27）
• cypress-cucumber-preprocessorは、集計を公式にサポートしていない複数のCucumber JSONレポートを生成します（https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/423）
• jest-cucumberはjest-cucumber-fusionほど便利ではありません
• cucumber-jestます...
• Karmaにはもう機能する実装がありません（https://github.com/cucumber/cucumber-js/issues/1095）

Jest / Karma / Cypress /などの間に最小限のグルーコードが表示されます。 とcucumber-jsなので、使用する必要のある

素晴らしい提案@davidjgoss👍

コマンドラインユーザーインターフェイスと、テストとしてシナリオを解析および実行する「ビジネスロジック」との間の関心の分離は、ヘキサゴナルアーキテクチャパターンを思い出させます。

cucumber-rubyでは、「クリーンルーム」でゼロから再構築していたため、実際にはコアドメインロジック（または「内部六角形」）を別のgemパッケージに分割しました。 これはここでのコンテキストではないことは理解していますが、この設計からインスピレーションを得たり、RubyAPIにイノベーションをフィードバックしたりする価値があるかもしれません。 cucumber-ruby-core gemのREADMEに、そのAPIの使用方法の例があります。

さて、これが「実行」ビットのAPI署名の最初のパスです。 これは、内部にあるIConfigurationオブジェクトに大きく基づいていますが（したがって、下の方にリファクタリングをあまり引き起こさないようにする必要があります）、「フラット」は少し少なくなります。

export interface IRunCucumberOptions {
  cwd: string
  features: {
    defaultDialect?: string
    paths: string[]
  }
  filters: {
    name?: string[]
    tagExpression?: string
  }
  support:
    | {
        transpileWith?: string[]
        paths: string[]
      }
    | ISupportCodeLibrary
  runtime: {
    dryRun?: boolean
    failFast?: boolean
    filterStacktraces?: boolean
    parallel?: {
      count: number
    }
    retry?: {
      count: number
      tagExpression?: string
    }
    strict: boolean
    worldParameters?: any
  }
  formats: {
    stdout: string
    files: Record<string, string>
    options: IParsedArgvFormatOptions
  }
}

export interface IRunResult {
  success: boolean
  support: ISupportCodeLibrary
}

export async function runCucumber(
  options: IRunCucumberOptions
): Promise<IRunResult> {
  // do stuff
}

そして、非常に工夫された使用例：

const result = await runCucumber({
  cwd: process.cwd(),
  features: {
    paths: ['features/**/*.feature'],
  },
  filters: {
    name: ['Acme'],
    tagExpression: '<strong i="10">@interesting</strong>',
  },
  support: {
    transpileWith: ['ts-node'],
    paths: ['features/support/**/*.ts'],
  },
  runtime: {
    failFast: true,
    retry: {
      count: 1,
      tagExpression: '<strong i="11">@flaky</strong>',
    },
    strict: true,
    worldParameters: {
      foo: 'bar',
    },
  },
  formats: {
    stdout: '@cucumber/pretty-formatter',
    files: {
      'report.html': 'html',
      'TEST-cucumber.xml': 'junit',
    },
    options: {
      printAttachments: false,
    },
  },
})

フィードバックを歓迎します！ これは、別の機能となるプロファイル/構成のロードに関するものをカバーしていないことに注意してください。

これはよさそうだと思います。 質問：カスタムフォーマッターをどのように構成しますか？

@nicojsはCLIのようなものです

formats: {
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

この@davidjgossの進捗状況を確認できてうれしいです。

これの進行を遅らせたくはありませんが、同時に、他のCucumber実装でも機能する形式を採用するようにしたいです。

最終的にはJSONスキーマですが、それについて説明している間、TypeScriptタイプは人間が解析しやすいと思います。

cucumber/commonモノレポで提案されたフォーマットに関する新しい問題を作成し、コアチームにそこで議論するよう招待することをお勧めします。

@aslakhellesoyが行います。

プログラマティックAPIが共通のオプション構造に関連付けられていないことについてどう思いますか？ それからrunCucumberオプションにマップするように。 少し複雑になるかもしれませんが、ロードするパラメータであるsupportブロック、または以前にロードされたサポートコードライブラリがあるなどの理由で魅力的です。 機能+ピクルスについても同様のことができます。 また、CLIでサポートするさまざまなオプション（例： --exit ）がありますが、プログラマティックAPIでは適切ではありません。

プログラマティックAPIが共通のオプション構造に関連付けられていないことについてどう思いますか？

オプションファイルの内容からrunCucumberが必要とするデータ構造に変換する関数を提供する限り、それは問題ないと思います。

最終的にはJSONスキーマですが、それについて説明している間、TypeScriptタイプは人間が解析しやすいと思います。

なぜ選択する必要があるのですか？ StrykerJSでJSONスキーマを使用して、 json-schema-to-typescriptを使用してtypescriptを生成していprebuildステップを使用してオンザフライで生成します。

JSONスキーマは、人間のIMOにとってはまだある程度読みやすいものです。 ストライカーレポにはすでにPRがあり、人々は何をすべきか知っているようです🤷‍♀️

CLIのように

formats: {
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

これは、出力ファイル名を必要としないレポーターに対してどのように機能しますか？ そのようです：

formats: {
  files: {
    '': require.resolve('./my-awesome-stryker-formatter')
  }
}

なぜ選択する必要があるのですか？

構成の構造の信頼できる唯一の情報源としてJSONスキーマを使用する必要があると思います。 -次に、そのスキーマからTypeScript / Java / Whateverコードを生成します。

しかし、JSONスキーマは人間にとっては少し読みにくいので、 cucumber/common GitHubの問題でスキーマについて議論している間、私は

私が何を意味するのか分かりますか？

JSONスキーマは、人間のIMOにとってはまだある程度読みやすいです。

私にはわかりません:-)冗長すぎます。

これは、出力ファイル名を必要としないレポーターに対してどのように機能しますか？

formats: {
    stdout: './my-awesome-stryker-formatter',
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

（stdoutストリームを使用できるフォーマッターは1つだけです）