過去にPythonにレタスを使用しました。これは、仕様が外部のプレーン テキスト ファイルに記述されている単純な BDD フレームワークです。実装では正規表現を使用して各ステップを識別し、仕様の各文の再利用可能なコードを証明します。
specs2またはscalatestのいずれかでscalaを使用すると、実装と一緒に仕様を書くことを余儀なくされ、別のテストで実装を再利用することができなくなります（確かに、どこかの関数で実装できます）。仕様自体からのテスト実装 (私が以前行っていたもので、検証のためにクライアントに受け入れテストを提供していました)。
結論として、私は私の質問を提起します:クライアントによるテストの検証の重要性を考慮して、scala が外部ファイルからテストをロードし、テストの文がまだ実装されていない場合に例外を発生させ、すべての文が実装されているかどうかを正常にテストしますか?
sbt 用のキュウリ プラグインを発見しました。テストは test/scala の下に実装され、仕様はプレーンな txt ファイルとして test/resources に保持されます。ライブラリの信頼性と、将来サポートされるかどうかはわかりません。
編集: 上記は、問題を完全に解決し、Scala をサポートする次のプラグインのラッパーです。 https://github.com/cucumber/cucumber-jvm
これはすべてトレードオフに関するものです。キュウリスタイルの仕様は、純粋なテキストであり、非コーダーが簡単に編集および読み取りできるため、優れています。
ただし、機能とGiven-When-Thenに基づいて厳密な形式を課すため、仕様としてもかなり厳格です。たとえば、 specs2では、必要なテキストを記述して、システムでのアクションまたは検証を目的とした行にのみ注釈を付けることができます。欠点は、テキストに注釈が付けられ、pendingまだ実装されていないものを示すために明示的に指定する必要があることです。また、注釈は、どこかに存在するコードへの単なる参照であり、もちろん、通常のプログラミング手法を使用して再利用性を得ることができます。
ところで、上記のリンクはトレードオフの興味深い例です。このファイルでは、最初の仕様は「醜い」ですが、ステップがステップWhenからの情報を使用しているGivenこと、またはステップからの情報がないことを示すコンパイル時のチェックがさらにあります。ステップのシーケンスThen -> When。2番目の仕様はより優れていますが、エラーが発生しやすくなっています。
次に、正規表現を維持するという問題があります。機能を作成する人とそれらを実装する人の間に厳密な分離がある場合、実質的な変更がなくても、実装を中断するのは非常に簡単です。
最後に、バージョン管理の問題があります。ドキュメントの所有者は誰ですか？コードが仕様と同期していることをどのように確認できますか？必要に応じて誰が仕様をリファクタリングしますか？
完璧な解決策はありません。私自身の結論は、BDDアーティファクトは開発者の手に渡り、他の利害関係者によって検証され、コードが読み取り可能である場合は直接コードを読み取るか、html/pdf出力を読み取る必要があるということです。また、BDDアーティファクトが開発者によって所有されている場合は、独自のツールを使用して、検証（可能な場合はコンパイラを使用）とメンテナンス（自動リファクタリングを使用）で作業を楽にすることもできます。
あなたは、Scala がこの種のスタッフ (メソッド、関数、トレイト、クラス、型など) に提供する通常のメソッドによって実装を再利用可能にするのは簡単であると述べたので、実際には問題はありません。
コードなしのバージョンを顧客に提供したい場合は、コード ファイルを提供することもできます。また、顧客が少しの構文を無視できない場合は、すべてのテキストをファイルに書き出すカスタム レポーターを作成することもできます。 as html などでフォーマットされていても。
もう 1 つのオプションは、JBehaveまたはその他の JVM ベースのフレームワークを使用することです。Scala で問題なく動作するはずです。