2013-04-24 14 views
7

ステップ、私はステップの定義で、私はこの不自然な例のような不格好なものをやっている瞬間の文字列が存在するかどうかをチェックしたい:ブールパラメータはSpecFlowで

[Given(@"Foo (bar)?")] 
public void GivenFoo(string bar) 
{ 
    if (bar == " bar") 
    { 
     // do bar 
    } 
} 

しかし、私は」このような何かをしたいとdは:

[Given(@"Foo (bar)?")] 
public void GivenFoo(bool bar) 
{ 
    if (bar) 
    { 
     // do bar 
    } 
} 

しかし、私は、そう、この可能であり、どのようにその場合どのように見つけることができませんか?

+0

この場合、ブール値フラグの意味は何ですか? 'two == false'のときに何かを2回行うことはどういう意味ですか? –

+0

これはメークアップの例なので、おそらく最善ではありません。私は、文字列が存在するかどうかをフィーチャー・ファイルのステップで見つける良い方法がほしいです。 –

+1

実際の例を見るとよいでしょう...シナリオを書く方法に問題があると私には思われます。 –

答えて

0

あなたが探している:

[Given(@"I do something (times) times")] 
public void GivenIDoSomething(int times) 
{ 
} 

そうでなければ、これは私はあなたが実際に手順を分離したいステップではなく、if声明と思い

[Given(@"I do something twice")] 
public void GivenIDoSomethingTwice() 
{ 
} 

EDIT

を十分に思われます。

+0

2回のビットを無視します。私は、この例題が完全なものであり、実際のコードではないことを明確にするために質問を編集しました。 –

+0

元々私はやっていましたが、それは抽出するのが難しい軽微な違いを伴うステップをもたらしました。クライアントを怒らせることなく、私たちが持っているものの例を投稿することはできません。 –

+0

あなたの手順は再利用可能な方法で実装する必要があります。シナリオで 'GivenFoo'ステップを2回使用できるようにする必要があります:' IDoFooとIDoFoo When xxxx Then yyyy'。 SpecFlowには、文字列の存在をチェックしブール値に変換するものはありません。 if(bar == "bar")は、私があなたのステップを再構築することなく私が考えることができる唯一の方法です。 –

1

あなたの質問とJakubの回答に対するコメントに基づいて、あなたのサイトを通じて複数のユーザー旅行をカバーできる1つのステップを作成しようとしているようです。 SpecFlowは実際にはこのために設計されたものではなく、シナリオ/機能の構造を改善して改善する必要があることを示すものです。

あなたの質問に直接答えるために、私はステップ定義の特定の文字列の存在に基づいて論理値を推論する方法はないと思います。

このルートを維持したい場合は、元の例がおそらく最適です。

このアプローチをとっておらず、代わりにステップ定義を再構築してシナリオをまたがって再利用することをお勧めします。私は実際にあなたのソリューションに合ったサンプルのステップ定義を考えるのに苦労しています。

マルチステップのアプローチの例は次のようになります。

Given I have logged in as an existing user //1 
And I have started my 6-step registration process //2 
And I have filled in valid address values on step 1 //3 
And I have left the fields blank on step 2 //4 
... etc 
When I save my registration 

そして、あなたの手順は次のようになります。ログインページに

  1. ナビゲート、有効なユーザーとして
  2. ナビゲートしてログインステップ1に戻る
  3. 有効な入力フィールドに「次へ」を入力してください。
  4. 「次へ」をクリックしてください

各ステップが可能な限り独立していることを確認するだけで、他のステップに微妙に異なるステップ(新しいシナリオの場合)を置き換えることができます。

このアプローチでは、複雑なシナリオ(場合によっては非常に冗長性のあるシナリオ)が残る可能性がありますが、これは賢明で多くのものを1つのステップ定義にまとめるよりも優れたソリューションだと思います。おそらく読めないシナリオになるでしょうし、コードはおそらく読み込み/保守の苦痛になるでしょう。

+0

> "...あなたのサイトを通して複数のユーザーの旅をカバーできる1つのステップを書き込もうとしていますが、SpecFlowは実際にこのために設計されていません" SpecFlowは、 「注意してください!ステップ定義をフィーチャに結合することは反パターンです」と言います。彼らはステップを再利用しないと言っているキュウリの文書にリンクしていても、ステップの定義が爆発的になり、コードが重複し、保守コストが高くなる可能性があるため、悪いです」 – LouD

0

StepArgumentTransformationメソッドを使用すると、間違いなくそのようなことができます。パーサーロジックを記述する必要がありますが、その構文解析を実行することだけが目的です。

例の機能ファイル:

Feature: I win if I am Batman 

Scenario: Happy 
    Given I am the Batman 
    Then I defeat the Joker 

Scenario: Sad 
    Given I am not the Batman 
    Then I am defeated by the Joker 

Specflowバインディング(C#の):

[Binding] 
public class IWinIfIAmBatmanFeature 
{ 
    private bool iAmBatman; 

    [StepArgumentTransformation(@"(am ?.*)")] 
    public bool AmToBool(string value) 
    { 
     return value == "am"; 
    } 

    [Given(@"I (.*) the Batman")] 
    public void WhoAmI(bool amIBatman) 
    { 
     iAmBatman = amIBatman; 
    } 

    [StepArgumentTransformation(@"(defeat|am defeated by)")] 
    public bool WinLoseToBool(string value) 
    { 
     return value == "defeat"; 
    } 

    [Then(@"I (.*) the Joker")] 
    public void SuccessCondition(bool value) 
    { 
     Assert.AreEqual(iAmBatman, value); 
    } 
} 

重要な要因は、あなたのGiven句の正規表現の一致がステップ引数変換で一致していることです。だからI (.*) the Batmanでは、キャプチャがAmToBoolの属性と同じように、StepArgumentTransformationの引数のキャプチャと正規表現が一致すると、それが使用される変換になります。