使用したコンテキスト - 正しいアプローチ

Question

behatでFooContextクラスを使用するための適切なアプローチは何ですか？

それは何docsである：

コンテキスト・クラスのためのシンプルなニーモニックがある：「コンテキスト内で機能のテスト」。 （...）、あなたはかなりこれらの機能をテストします方法は、あなたがそれらをテスト文脈に依存しています。

ドキュメントにはあなたが速く作成できるように、私は唯一のダミーコンテキストファイルであるためには思わFeatureContext行動テスト。

コンテキストクラスはFeatureContextと呼ばれるべきです。これは、Behatインフラストラクチャ内の簡単なコンベンションです。 FeatureContextは、デフォルトスイートのコンテキストクラスの名前です。

フィーチャーごとにコンテキストファイルでなければならないと私は直接言っていません。

ドキュメントで唯一の本当の他の例は、ApiContextまたはWebContextような状況です。私もCommandFeatureと別のCommandLineProcessContextがわかった何

default: 
    suites: 
     web_features: 
      paths: [ %paths.base%/features/web ] 
      contexts: [ WebContext ] 
     api_features: 
      paths: [ %paths.base%/features/api ] 
      contexts: [ ApiContext ] 

。

私はテストする多くの機能を持っているので、コンテキストファイルが非常に高速になります。

次に、フィーチャ例ごとにMarco Pivettaによってコンテキストファイルが表示される可能性があります。Aggregate as Contextを使用しています。

は、機能foo.featureごとに単一のコンテキストファイルを持っているのは良いアイデアですか？あるいは、コンテキストファイルは、文書ApiContextまたはWebContextのような環境コンテキストと考えられていますか？

Answer 1

通常、私は次のように文脈や機能を分割することを好む：各ドメインの対象のための

• 一つは、フォルダ
• これは

テーマにあなたが行うことができ、各アクションの一つの特徴/コンテキストファイルそうすれば、2つ以上のコンテキストを使用して、すべてのコンテキストを1つの責任で分けて、1つのスイートを完成させることができます。

クイック例

Features 
|--- User 
|----- login.feature 
|----- change_password.feature 
|----- impersonate.feature 
|----- ban.feature 
|----- ... 
|--- ... 
|--- Order 
|----- checkout.feature 
|----- cancel.feature 
... 
Context 
|--- User 
|---- LoginContext 
|---- ChangePasswordContext 
|---- ImpersonateContext 
|---- BanContext 
|---- ... 
|--- Order 
|---- CheckoutContext 
|---- CancelContext 

各スイートには、多くのコンテキスト（たとえば、あなたが行動をチェックするにはログインする必要があるたびに、あなたのスイートでLoginContextを含めます）で構成されています。

default: 
    suites: 
    suite_name: 
     paths: 
     - '%paths.base%/Path/To/Feature/File' 
     contexts: 
     - Path\To\Context\LoginContext 
     - Path\To\A\SecondContext 
     - ... 

このアプローチは、保守性、直観性などの点で多くの利点があります。

あなたはこのテーマに、より汎用的なパノラマを持っているしたい場合は、あなたの答えのためのcheck slides from my talk at Symfony day 2017 in Milan