4

これは私が遭遇した興味深いトピックであり、私の同僚と私はこの問題について異なる意見を持っています. Gherkin は、テストが何を行っているかを正確に説明する必要があります。または、テストで達成しようとしたビジネス ロジックのみを表示する必要があります。

私が職場でよく遭遇する最大の例は、アイテム A にアクセスできる場合は、A にアクセスできるはずだということです。A にアクセスできるユーザーには 20 種類のユーザーがいる可能性があるため、1 つだけを選択します (テスト スイートの実行に 40 時間もかからないようにするためです)。では、どちらが「より良い」でしょうか？

あ

Scenario: A user with access to item A can access A
Given I am a type 4 user with access to item A
When I try to access A
Then I am granted access to A

またはB

Scenario: A user with access to item A can access A
Given I am a user with access to item A
When I try to access A
Then I am granted access to A

与えられたステートメントの違いに注意してください (タイプ 4 ユーザー)

ステップ定義では、テストにタイプ 4 のユーザーを使用する予定ですが、テストはタイプ 4 のユーザーに固有のものではありません。アイテム A を持つすべてのユーザーがこのテストで機能します。ログインにユーザー タイプが必要なため、タイプ 4 のユーザーを使用しています。

したがって、A はテストの内容を説明します (アイテム A へのアクセス権を持つタイプ 4 ユーザーでログイン)

B は、アイテム A にアクセスするために必要な機能を説明します (アイテム A にアクセスできるユーザーのみ)。

質問する前に、アイテム A へのアクセス権を持つユーザーを特定する方法は、ユーザーにリンクされた特定のアイテムを検索するデータベースへの SQL 呼び出しです。

4

3 に答える 3

8

きゅうりのテストでは、特定の実装の詳細ではなく、受け入れテストとしてビジネス ロジックをテストします。したがって、最初ではなく 2 番目を実行する必要があります。タイプ X、タイプ Y、およびエッジ ケースのテストを実行する場合は、要求仕様または統合テストを詳細に結び付けることができます。

私はこれを次のように考えることができると思います-そしてそれは難しい速いルールではありません-

メソッドを分離し、一度に 1 つのことをテストする単体テスト。他のすべてをモック & スタブして、テスト対象を分離します。

複数のオブジェクトの相互作用を含む、スタックの大部分をテストするために、物事がどのように相互作用するかをテストする統合テスト。ここですべてを徹底的にテストすると主張する人もいますが、大規模で複雑なアプリには、統合された多くの部分をテストしながら、まだ完全な要求サイクルをテストしていない場所があると思います。

リクエスト スペック - 単純なアプリでは、これらは統合テストとほとんど同じである場合があります。それ以外の場合は、リクエスト スタックを除くすべての統合テストを行い、特にリクエスト スペックを分離します。意見はさまざまです。

受け入れテスト - これはあなたが質問をしている場所です - テストは平易なビジネス言語で書かれており、機能定義内の技術的な実装の詳細を避けています.

とにかく、テスト スタックの残りの部分についての考えを無視したとしても、あなたが求めている特定の質問では B を選択してください。

于 2013-03-26T02:02:21.397 に答える
0

オプションBの方が良いと思います。「タイプ 4 ユーザー」は実装の詳細のように聞こえます。

ただし、すべてのユーザー タイプがアクセスできることが要件である場合は、それも仕様の一部を形成する必要があります。その場合、テストではすべてのユーザー タイプを指定してテストする必要があります。

于 2013-03-26T16:27:11.487 に答える