1

私はこれらのどちらかがうまくいくことを知っていますが、私はルビー/キュウリコミュニティのより良いメンバーになろうとしています。ウェブサイトの複数のセクションにリンクがないかどうかをテストするストーリーがありますが、表示されないはずです。したがって、これら2つの方法のどちらが、シナリオを作成するための最良の方法です。繰り返しになりますが、どちらも機能することは理解していますが、ベストプラクティスソリューションを探しています。オプションBはすべて異なる「Then」ステップをテストしているため、通常はオプションBを使用します。しかし、私はいくつかの調査を行っており、同じステートメントですべてのシナリオをテストできるので、自分自身を推測しています。「与えられた」と「その後」の両方の手順を変更する場合にのみ、新しいシナリオを作成する必要があると読んでいました。 。

A。

Scenario: A user that cannot access A, B, C, or D
    Given I am a, user without access to A, B, C, or D
    When I navigate to reports
    Then I see the A header
    But I cannot click on A's header
    And I see error message under A stating the user does not have access
    And I do not see the B section
    And I do not see the C section
    And I do not see the D section

また

B。

Scenario: A user that cannot access A
    Given I am a, user without access to A
    When I navigate to reports
    Then I see the A header
    And I see error message under A stating the user does not have access
    But I cannot click on A's header

Scenario: A user that cannot access B
    Given I am a, user without access to B
    When I navigate to reports
    Then I do not see the B section

Scenario: A user that cannot access C
    Given I am a, user without access to C
    When I navigate to reports
    Then I do not see the C section

Scenario: A user that cannot access D
    Given I am a, user without access to D
    When I navigate to reports
    Then I do not see the D section
4

3 に答える 3

1

ベスト プラクティスは、機能をさまざまな部分 (この場合はシナリオ) に分解することだと思います。

オプション B は、単一責任の原則 (もちろん、コードのさまざまな部分に適用できます) に準拠しているため、より優れています。B の書き方は明確で直接的です。6 か月後にこれに戻った場合、または新しい開発者がこれを初めて見た場合、両者ともテストの目的をよく理解しています。

オプション A は多くのことを行っているようです。これは統合テストですが、テストするコードの特定の部分を可能な限り独立させておく必要があります。このテストが失敗した場合、その理由が正確にわかりますか? または、テストのどの部分が実際に失敗したかを確認するために掘り下げ始める必要がありますか?

このコンテキストでのベスト プラクティスでは、コードのセクションを小さくすることを推奨しています。これらのテストが繰り返され始めた場合 (DRY、繰り返さないでください)、リファクタリングを開始できます (Backgroundおそらく)

于 2013-03-07T19:35:25.337 に答える
1

詳細なシナリオは、目的の動作をより明示的に伝え、回帰が発生した場合により適切な診断を提供するため、推奨されます。アプリケーションが進化するにつれて、小規模なシナリオは保守が容易になります。長いシナリオは「引力」を発達させ、さらに長くなります。長いシナリオでは、すべてのセットアップとステップの副作用を把握することは困難です。その結果、長いシナリオが成長し続ける「引力」が生まれます。

シナリオの概要により、テストを詳細かつ簡潔にすることができます。次の例では、リソース B、C、および D がすべて同じポリシーを持っているのに対し、リソース A は異なることが一目でわかります。

Scenario Outline: A user cannot access an unauthorized resource
    Given I am a user without access to <resource>
    When I navigate to reports
    Then I do not see the <resource> section

    Examples:
        | resource |
        | B        |
        | C        |
        | D        |


Scenario: A user that cannot access A
    Given I am a, user without access to A
    When I navigate to reports
    Then I see the A header
    And I see error message under A stating the user does not have access
    But I cannot click on A's header
于 2013-03-09T17:38:33.163 に答える
0

ABC や D を読みやすいものに置き換えます。おばあちゃんはこの定義を理解する必要があると考えてください。ABCD が何を意味するのか理解できないでしょう。だから、こう言いましょう

与えられた基本的なユーザー.. .. そのユーザーは編集ツールを見ることができません

スーパーユーザーを指定すると.. ..スーパーユーザーには編集ツールが表示されます

グループ名、レベルn、チームなどの意味のあるABCDに参加してみてください

次に、各項目の 1 つに TestUnits を使用します。

于 2013-03-07T20:20:56.853 に答える