7

命令型と宣言型の cucumber stepsの違いは理解していますが、これの実例は見たことがありません。機能ファイルが冗長になりすぎているといつも感じています。

ライフ サイクルの各ステップにキュウリの機能が必要なようです。

  • foobars/list_foobars.feature
  • foobars/create_foobar.feature
  • foobars/view_foobar.feature
  • foobars/edit_foobar.feature
  • foobars/delete_foobar.feature

作成機能だけで、入力できるフィールド、必須のフィールド、無効なデータを入力するとどうなるかなどをリストしたいようです。これを行う宣言的な方法はわかりません。もちろん、後続の機能では、Given a foobar existsすべての手順を実行して作成するのではなく、単に言うだけです。

アプリケーションの動作を説明するとき、どの程度詳細に説明しますか? 十分に完成していると思われる機能ファイルの例をいくつか挙げていただけますか?

4

2 に答える 2

4

私はキュウリのテストを人間が読めるようにしておくのが好きなので、無効なデータを含む foobar を編集するというストーリーがあると仮定すると、次のようなシナリオが必要になります:

# foobars/edit_foobar.feature
Feature: As a user, I want to edit a Foobar, so I can Baz

Scenario: Validation Errors
  Given I am logged in as a user
  And a foobar exists
  And I edit the foobar with invalid data
  Then I should see validation errors

どのフィールドを編集するか、どのボタンを送信するかなどのすべての詳細に対処する必要なく、ストーリーから私たちが望むものを捉えていると思います。考えられるすべてのケースをテストするわけではありませんが、それらは実際に次の方法でテストする必要があります単体テスト (検証が設定されているモデル テスト、フラッシュ メッセージが設定されているコントローラー テスト、またはエラーが処理されている要求テスト)。

他のシナリオも同様です。

Scenario: Successful Edit
  Given I am logged in as a user
  And a foobar exists
  And I edit the foobar with valid data
  Then I should see the valid data

テスト自体の一部として有効なデータを指定したい人もいますが、個人的には、シナリオをきれいに保つために、これらをステップ定義に委任することを好みます。ゴールデン ケースが機能することを確認するために必要な例は 1 つだけです。これも、すべてのフォーム フィールドが機能することをテストする適切な場所ではないためです (すべてのフィールドを指定すると、メンテナンスの頭痛の種になります)。

于 2013-06-26T03:43:50.443 に答える