7

SpecFlowの背後にある概念やアイデアを完全に理解していると思いますが、Secret Ninja Cucumber Scrolls、The Cucumber Bookを読んだ後でも、さまざまなフォーラムを読んだ後でも、再利用性への道はまだわかりません。

私たちのシナリオはすでにさまざまなガイドラインに準拠しています

  • 自明
  • 理解できる目的を持っている必要があります（他のシナリオとの違い）
  • ユニークです
  • 垂直機能スライスを表す
  • ユビキタス言語を使用
  • 利害関係者の観点から書かれた
  • ソフトウェア設計ではなく、ビジネス機能について
  • 叙事詩によるグループ化
  • テストスクリプトではありません
  • シナリオが正しいかどうかを確認するために、他の誰かに読んでもらいます
  • UI要素を参照しません
  • 重要な例を表す
  • 非技術的な
  • 正確でテスト可能
  • 可能な限り再現可能
  • 「与えられた」は、アクションではなく状態を表します
  • 「いつ」はアクションを表します
  • 「Then」は、内部イベントではなく、目に見える変化を表す必要があります

手順は、次のガイドラインに準拠する必要があります（一部はSpecFlowに固有です）。

  • ユビキタス言語を使用
  • UI要素を参照しません
  • 組み合わせてはいけません
  • すべての機能で再利用可能でグローバルである必要があります
  • 特定の機能にリンクしないでください
  • エンティティ、エンティティグループ、またはドメインの概念ごとにグループ化
  • ステップ定義ファイルでロジックを再利用するステップを作成しないでください
  • ステップが属するステップファイルをよく考えてください
  • フェーズ間のステップを再利用しないでください
  • ステップ内のリテラル文字列は避ける必要がありますが、必要に応じて一重引用符を使用してください
  • ステップメソッドに複数の[Given]、[When]、または[Then]属性を適用しないでください
  • それらが表すフェーズに従ってステップを順序付けます
  • シナリオにとって重要でない場合は、言うまでもなく非常に重要です

ただし、正規表現プレースホルダーを使用した場合でも、同じ手順のバリエーションがたくさんあります。特に、何かが重要でない場合、それがそれらの変動をもたらすことを言及するべきではないという規則。そして、はい、内部的にこれらのステップは多くの再利用を行いますが、シナリオではそうではありません。

たとえば、次のシナリオを考えてみましょう。

Feature: Signing where both persons are physically available

@Smoke
Scenario: Show remaining time to sign based on previous signature
  Given a draft proposal
  And the first signature has been set
  When I try to set the second signature
  Then the remaining time to sign should be shown

@Smoke
Scenario: Re-signing of the first proposal
  Given a signature that has not been set within the configured time
  And the first signature has just been re-signed
  When I try to set the second signature
  Then the remaining time should start over

2つの「与えられた」ステップを1つに組み合わせて、再利用性をいくらか失う方がよいでしょうか。

他のいくつかの例：

Feature: Conditionally show signatures to be signed

@Smoke
Scenario: Show the correct signature for a proposal with a night shift
  Given I have a proposal for the day shift
  When I change it to the night shift
  Then I should only be able to sign for the night shift

@Smoke
Scenario: Show additional signature when extending the shift
  Given I have a suspended proposal for the night shift
  When I extend the period to the day shift
  Then I should confirm extening the period over the shift

ここで基本的な概念が欠けていますか？

4

2 に答える 2

12

これは答えではありませんが、いくつかのヒント:

  • 複数の Give/When/Then 属性を同じメソッドに配置できます。パラメータが同じで、違いがフレージングのみの場合、これは便利です。
  • 多くのプロジェクトでは、ドライバー/ページ オブジェクト パターンを使用するため、通常、ステップ定義は非常に短い (2 ～ 3 行) ため、それらの数についてあまり気にしません。
  • 私はあなたのシナリオが好きです、私はそれらを変更しません。一方、再利用性ではなく、読みやすさに焦点を当てるようにしてください。言語に一貫性があれば、再利用性が向上します。
  • 特に、話しているエンティティに多くの「バリエーション」がある場合に再利用性を高めるために、ステップ引数変換の使用を検討できます。次に例を示します。

装飾を使用してテストで許可を表すクラスが必要です。

class PermitDescription{
  bool suspended;
  bool draft;
}

コンバーター メソッドを作成します。

[StepArgumentTransformation("permit")]
public PermitDescription CreateSimple(){
  return new PermitDescription();
}
[StepArgumentTransformation("draft permit")]
public PermitDescription CreateDraft(){
  return new PermitDescription() { draft = true; }
}
[StepArgumentTransformation("suspended permit")]
public PermitDescription CreateSuspended(){
  return new PermitDescription() { suspended = true; }
}

許可を必要とするより柔軟なステップ定義を持つことができるようになりました:

[Given(@"I have a (.*) for the day shift")]
public void Something(PermitDescription p)
{ ... }

一致するもの:

Given I have a permit for the day shift
Given I have a draft permit for the day shift
Given I have a suspended permit for the day shift

もちろん、これは悪用される可能性のあるツールですが、場合によっては役立ちます。

于 2012-07-13T07:54:47.087 に答える