11

サブコンテキスト クラスに別のサブコンテキストを拡張させ、関数をオーバーライドさせることは可能ですか?

現在、私は

class TestContext extends BehatContext {
    /**
     * @Given /^a testScenarioExists$/
     */
    public function aTestscenarioexists() {
        echo "I am a generic test scenario\n";
    }
}

と

class SpecialTestContext extends TestContext {
    /**
     * @Given /^a testScenarioExists$/
     */
    public function aTestscenarioexists() {
       echo "I am a special test scenario\n";
    }
}

機能のコンテキストでは、サブコンテキストとしてそれを伝えますSpecialTestContext。

テストビートを実行すると、

[Behat\Behat\Exception\RedundantException]
ステップ "/^a testScenarioExists$/" は SpecialTestContext::aTestscenarioexists() で既に定義されています

誰かがこれで正しい方向を教えてくれますか?

なぜこれを達成しようとしているのかについてさらに情報を提供するために、私が達成しようとしているのは、さまざまな環境でシナリオを実行し、gherkin ファイルで環境を指定する機能です。たとえば、次のようになります。

Scenario: Test with generic environment
Given I am in the environment "generic"
    And a test scenario exists

Scenario: Test with specialised environment
Given I am in the environment "specialised"
    And a test scenario exists

次に、いくつかのコードを追加FeatureContextして、正しいサブコンテキストをロードできます。

4

3 に答える 3

4

要するに...これは不可能です: http://docs.behat.org/guides/2.definitions.html#redundant-step-definitions

サブコンテキストを動的にロードするという点では、これは不可能です:

  1. サブコンテキストは「コンパイル時」にロードされます。メインの FeatureContext コンストラクターで
  2. 最初のステップ定義が実行されるまでに、behat はすでにすべての注釈を収集し、それらをステップ定義にマップしています。これ以上追加することはできません/すべきではありません

Contextこれをチェックして、 a の動作 を理解してください: http://docs.behat.org/guides/4.context.html#contexts-lifetime

考慮すべきいくつかのより広い事項：

  1. ガーキン シナリオでキャプチャされたものはすべて、非開発者 (または少なくともシステムを作成していない開発者!) が理解できる必要があります。シナリオは、コードを掘り下げることなく、1 つの (理想的にはそれ以上ない) ビジネス ルールを完全に伝える必要があります。

  2. ステップ定義であまりにも多くのロジックを隠したくない場合は、すべてのルールをガーキン シナリオでキャプチャする必要があります

  3. FeatureContext をどのように整理するかはあなた次第ですが、システム内のテーマ/ドメインごとにこれを行う必要があります。たとえば、次のようになります。

    • aDatabaseContextは、テストデータベースへの読み取りと書き込みに関係している可能性があります
    • システム内の API の検証に関する手順が含まれているApiContext場合があります
    • システムコンソールコマンドの検証に関心があるCommandContextかもしれません
于 2013-04-08T23:36:31.863 に答える