複数の役割のためのガーキンA単一機能

Question

私のユビキタス言語として、私は、のようないくつかのフレーズを持っている：

Feature : Display A Post 
In order to be able to check mistakes in a post 
As an admin or customer 
I want to be able to view the post 

Scenario : Display Post 
When : I select a post 
Then : the post should be viewed 

は、右のユーザーストーリーということですか？このようなシナリオでは、UIレベルで多少の違いがあります。 DRY principleに違反し、別の役割のためにこの機能を繰り返す必要がありますか？

さまざまなユーザーが時間の経過とともに異なる要件を必要とする可能性があります。私はこれがユーザーロールごとにユーザーストーリーを作成する理由だと考えています。異なるロールのために要件がどのように変化するかについて心配する必要があります。複数の役割を持つ単一のuser story（および同じテストコード、プロダクションコード、データベース...）と、それらの要件によって私がそれらの分離を余儀なくされたときrefactor？

Answer 1

私はここであなたの問題が何かを推測しようとしているか分かりません。最初の3行は説明だけであり、実際の手順ではありません。これにより、実行されないカスタムテキストを追加することができます。

あなたの他の2つのステップについては、彼らが良いかどうかを言うのは非常に難しいです。あなたがすでに気付いていたかもしれないが、あなたは特定のシナリオフローを持つためにキュウリに拘束されていません。キュウリは、あなたとあなたのビジネスロジックにとってより意味のある方法で、コードを設計して書く自由を与えます。

他の役割をテストするために同様の手順を繰り返しても問題はないと言っています。フィーチャファイルをDRYにするには、Scenario Outlineオプションを使用できます。それはこのようなものになります。この場合

Scenario Outline: Display Post as <role> 
    When I select a post as <role> 
    Then the post should be viewed 

    Examples: 
    |role | 
    |role1| 
    |role2| 

を、2つのシナリオは、例のリストに従ってrole値が変化しながら、次々と実行します。

今、あなたの将来の可能性のある変更について。将来的に何が起こるかを常に予測できるとは限りません。また、現在の要件を継続的に変更することがあなたやあなたのチームの通常の練習でない限り、私はこれについてあまり心配しません。将来の現在のシナリオで時折、時代遅れになる場合は、それらを見直して書き直したり、それに応じて新しいシナリオを追加したりします。

Answer 2

ここでの問題は、あなたがここでやりたいこととその重要性を明確にするために洗練が必要なあなたの言語です。

投稿者が投稿を間違えてしまうのは、私が必要とするのは投稿を変更できることです。

同様のことが顧客に適用されます（それは著者であるべきですか？）。投稿が間違いで書かれているときに何をするのかを調べると、さまざまな役割がさまざまなやり方でやりとりされていることがわかります。顧客と管理者が修正を加えた場合の対応や、管理者が気に入らない修正やその他のシナリオを行った場合の対応方法について質問を開始します。

これを行うと、ほとんどの複製がなくなり、この特定の状況での顧客と管理者の動作の違いについて多くのことがわかります。

Answer 3

機能に複数の役割が必要な場合は、機能ではなく叙事詩であることを意味します。各機能を細分化して1つの役割しか持たないようにする必要があり、単一のユーザーグループに単一の価値を提供することができます。