大規模なアプリケーション用に機能とステップ定義のスケーラブルな構造を作成しようとしています。最初のショットは、step_definitionファイルを機能にリンクして、異なるステップ定義に同じステップパターンを使用できるようにすることでした。

とても興味深い。 cucumber-jsには、あなたが示したcucumber-javaの例のように何も組み込まれていません。 この種のことで私が好きなアイデアは、このロジックの切り替えをワールドセットアップまたはインスタンスにプッシュすることです。 いずれにせよ、ステップ定義は1つだけになります。 サポートコードを定義するときに切り替える複数のワールド定義を使用することも、コンテキストに基づいてさまざまなメソッドを公開する単一のワールドインスタンスを使用することもできます。 現在、現在のシナリオのファイルを実行中のステップに公開していませんが、タグを使用してコンテキストを判別できます。

私たちは実際にこれに対して同じ必要性を持っています。 私たちはナイトウォッチキュウリを使用してセレンテストを実行しています。現時点での唯一の解決策は、各ステップにプレフィックスを追加することです。

Given [comp1] I click on "Open dialog"

vs

Given [comp2] I click on "Open dialog"

これにより、あいまいなステップ定義を回避できますが、機能ファイルが実際に読み取れなくなります。
cucumber.jsソースをいじってみましたが、この機能のサポートを追加するための良いヒントが見つかりませんでした。

これは、いくつかのフックまたは代替の世界で実現できますか？

@leipertどのユーザーインターフェイスを想定していますか？ このロジックは、世界に存在するか、複数の世界のオブジェクトをサポートする必要があると思います。 次に、ステップ定義は、ガーキンの一致を解析し、それらを適切なワールド関数に渡すことだけを扱います。 使用するワールドオブジェクトを選択するためのCLIオプションを追加できます。

今のところ、複数のワールド/ステップ定義が必要な場合は、コードを別々のフォルダーに配置し、実行ごとに1つだけ必要とすることでこれを実現できます（--require CLIオプションを使用）。

ええと、「きゅうりの本」は、この方法で手順を設計することを特に思いとどまらせます。 ステップは設計によりシナリオ間で共有されます。同じ文は、それを使用する機能にもかかわらず、一貫した意味を持つ必要があります。 手順の範囲を紹介すると、言語トラップを作成するのは非常に簡単です。

これまでのところ、cucuber.jsでの目的に近いのはタグだけです。 ただし、タグに固有であると宣言できるのはフックだけです。 それがあなたの人々にとって正しい方法であると確信しているなら、おそらくステップパターンの[機能名]のように単純なDSLを発明するかもしれません。

ありがとう、 @pinxue 。 非常に便利な応答。 しかし、私はそれを理解することはできません：

ええと、「きゅうりの本」は、この方法で手順を設計することを特に思いとどまらせます。

同じアクションフレーズは、異なるコンテキストで異なる意味を持つ可能性があります。 でも、大丈夫です。 私が持っているオプションを知っておくのは良いことです。実際、私たちはすでにそれを達成するために内部DSLを歩いています。

どうもありがとう。

@pinxueと@robsonrosaの回答ありがとうございます。
スコープ付きステップ定義の理由は次のとおりです。

1. _グローバル変数は不良であり、スケーリングされません_：
   それぞれ10のシナリオを持つ約15の機能ファイルファイルがあり、すべてのステップ定義と機能ファイルを構造化することはすでに困難です。 どの機能ファイルがどのステップを使用しているかを追跡するのは非常に難しいため、すべてのステップがグローバルに定義されている大きなアプリケーション（たとえば、10のシナリオで100の機能ファイルと平均5つのステップ）の場合、非常識に思えます。
2. _開発者は機能ファイルの文言を制御できません_：
   私たちのユースケースでは、私たちの「管理者」が機能ファイルを作成し、それらを販売するのは困難です。私たちは素晴らしいBDDを実行しますが、厄介なカスタムDSLに制限する必要があります。
3. _cucumber-jvmにオプションがある場合、なぜcucumber-jsを使用しないのですか？_
   これは悪い議論かもしれません💃

私たちの問題を解決するために、次のアプローチがあります。

1. ステップ定義にプレフィックスを使用してカスタムDSLを作成する
   短所：一緒に作業するのは良くありません。
   長所：cucumber.jsを変更する必要はありません
2. cucumber.jsのglueを作成します
   短所：「キュウリの本」の考えに反する可能性があります。
   長所： cucumber.jsとの機能の同等性
3. テストの実行方法を変更する
   短所：この機能は、より少ない人数で利用できるようになります。
   長所：cucumber.jsを変更する必要はありません

そうは言っても、cucumber.jsのメンテナが、スコープされたステップ定義がこのプロジェクトのスコープ外（しゃれを意図したもの）であると考える場合は、おそらく3を使用します。

@robsonrosa解決策があれば、私はあなたの解決策に興味があります。

IMOスコーピングは間違いなく必要です。 アプリケーションが大きくなるにつれて、機能の数が増え、さまざまなコンテキストで説明が競合することになります。

私の会社では、当社の製品には数百の機能があり、QAには10万の範囲のテストケースがあります。
cucumberを使用すると、間違いなくこの問題が発生します。

はい、スコープではなくコンテキストを考慮する必要があると思います。
すべてではないにしても、ほとんどのステップ定義をデフォルトのコンテキスト（またはコンテキストなし）に含めることができますが、カスタムDSLを必要とせずにコンテキストを指定する方法があるはずです。

これらのテストを作成するのはBAとQAであり、カスタムDSLは混乱と抵抗を生み出すことになります。

機能/シナリオはすでに定義によりコンテキストを提供しているため、Gherkin構文にはインデントがあります。

タグとカスタムDSLの追加は、ソリューションではなく、実装制限（つまり、ハック、IMO）の回避策です。

https://github.com/cucumber/cucumber-js/issues/745を検討しながら、これを検討できるかもしれません。

defineStep Scenarioを拡張し、 {Given, When, Then}をコールバックに渡すのはどうですか？

すなわち：

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

私はhttp://fitnesse.org/からBDDを学んでいるので、キュウリのコミュニティとはBDDの見方が違うかもしれません。

ページング@richardlawrence

これは、キュウリが特に注目されている分野です。 これは、チームがユビキタス言語を成長させる必要があるという信念に基づいて構築されています。この言語では、単語やフレーズは、アプリケーションのコンテキストで正確に1つのことを意味し、一貫して使用されます。 step defsをグローバルに保つことで、あいまいさを回避するためのポジティブなプレッシャーが維持されます。

アプリケーションに複数の異なる境界コンテキスト（DDD用語で）があるまれなケースでは、アプリケーションがその境界を反映するように分割されるのと同じ線に沿ってCucumberスイートを分割するだけで、ステップ定義は各境界コンテキスト内でグローバルになります。

Cucumberの操作と境界の作成に関する記事。 このページのアイデアのいくつかを実装していますが、 @ richardlawrenceが、ステップ定義の特定のクラスに焦点を合わせるようにCucumberを構成できないと述べているため、優れたソリューションは提供していません。 http://confessionsofanagilecoach.blogspot.com/2017/05/teaching-cucumbers-about-boundaries.html

@leipertが言ったように、グローバル変数は悪いです。 CucumberJVMの世界にいる私たちの話は、半分しか話されていないと思います。 Cucumber（JVM以外）は、シナリオの期間中のグローバルメモリスペースである整頓されたワールドコンセプトを使用します。 シナリオが実行された後、シナリオは破棄されます。 これは良い解決策のように感じます。 しかし...CucumberJVMでこのパターンの適切な実装を見ていません。 したがって、Cucumberがステップ定義用のフラット/グローバル名前空間を強制し、CucumberJVMがWorldパターンを実装するための明確なデザインパターンを持っている場合、私は少し幸せです。 この時点まで、CucumberJVM+ワールドパターン==非常に複雑なソリューション。 これまでのところ、私が見たものはすべて、どのステップ関数がどの機能ファイルに対応するかを単に制御できるようにするよりも複雑です。 これまでのところ、私が見た選択肢は、すべての努力/複雑さに対してこれ以上価値のあるものは何もありません。 他の種類のキュウリは、より良い世界の解決策を持っています。

最終的に、ワールドパターンを使用しても、機能ファイルからステップに移行するときに情報が失われることがわかっているため、私はまだ不満を持っています。 機能ファイルを適切な組織に配置する、適切な機能ファイル名を作成する、スマートな方法で機能を宣言する、スマートな方法でシナリオに名前を付けるなど、多大な労力を費やすと、すべてのコンテキストがウィンドウから外され、強制されますグローバルステップ定義名前空間を操作します。

関係をシステムの検証から除外し、テストのパスにワイルドカードを追加して、オープンソースフレームワークの変更が必要な場合でも、それらを機能させることしか考えられません。 私たちのプロジェクトが成長するにつれて、それを試してみるかもしれません。

私はあなたの目標を理解していますが、私はそれをお勧めしません。
また、バックグラウンドステートメントまたはこれを明示的にする追加のGivenステップのいずれかを使用して、明示的な.featureファイルを用意することをお勧めします。

または、2つの異なる構成ファイルを作成することもできます。
1つはサンプル用で、もう1つは例用です。
次に、別のステップフォルダを指すことができます。

@robsonrosa@ leipert私はあなたの意見を共有します
元の投稿からほぼ2年後...
それで何か進歩はありましたか？ 回避策はありますか？

@ cristianmercado19申し訳ありませんが、いいえ。 私はもうキュウリjsを使用していません。

Ups...ステップの実装から完全に分離された機能ファイルを作成する方法が好きです。
私は_mocha_で同じ目標を達成しようとしましたが、満足していません。
私の目標を達成する他の選択肢があれば、ぜひ試してみてください。
@leipertの助けに感謝します。

このスレッドは、閉じられた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。