3

倉庫内の同じコンテナーに追加されるかどうかにかかわらず、アイテムに関するルールを適用するためのクラスを作成する必要があり、実装する前に要件を Cucumber に変換したいと考えています。

各アイテムには、「アイテム ファミリー」(例: 電子機器、書籍)、「アイテム ステータス」(例: メイン在庫、不良在庫)、および「バッチ」(例: 1050、1051) などのいくつかの属性があります。

このための Cucumber テストを作成するためのいくつかの戦略を考えることができます。推奨されるものを知りたいです。

まず、製品ごとにすべての属性を列挙できます。

Given I have a tote containing:
  | sku    | client  | family  | status | batch | weight |
  | 100000 | Foo     | garment | main   | 1234  |     10 | 
When I add the item:
  | sku    | client  | family  | status | batch | weight |
  | 200000 | Bar     | garment | main   | 1234  |     10 |
Then I should be told there is a Client conflict

次に、基本的な製品をハードコーディングして、それと異なる最小限の属性を指定してみてください。

Given I have a tote containing an item that's client "Foo"
When I add an item that's client "Bar"
Then I should be told there is a Client conflict

これは、ステップ定義が基本的な属性を保持していることを前提としており、属性がステップで言及されている場合はそれらをオーバーライドします。

最後に、抽象化をさらに進めることができます。

Given I have a tote containing an item
And I add an item with a different client
Then I should be told there's a client conflict

ここで正しいアプローチに関するガイダンスはありますか?

4

2 に答える 2

1

The Cucumber Bookからの回答は、チームの技術者ではないメンバーにとって最も読みやすいものになります。QA リーダーとプロジェクト マネージャーと一緒に座って、同じ質問をします。私は同様の問題を抱えていて、あなたの最初の提案のようなものから始めました. その後、詳細すぎると判断し、#3 にジャンプしました。その後、プロジェクト マネージャーと話し合ったところ、データを作成しているときは詳細は必要ありませんでしたが、データを変更したとき (この場合は請求書の明細項目の値を更新したとき)、それらが何なのかを確認したかったことがわかりました。値はステップにありました。

The Cucumber Book の第 6 章「When Cucumbers Go Bad」は、適切な詳細レベルに向けるのに非常に役立ちました。特にユビキタス言語を考え出す部分については、ぜひ読んでいただきたいと思います。これは、組織にとって適切な詳細レベルを決定するのに役立つと思います。

最初のテストを使用したい場合は、「これらの値をどのくらいの頻度で変更しますか?」という質問をすることになります。答えが「あまりない」または「まったくない」の場合は、それらがテストの読みやすさを向上させているのか、それとも低下させているのかを検討する必要があります。

PS 私はまだThe Cucumber Bookを読んでいますが、これまでのところ非常に役に立ちました。

于 2012-04-16T16:38:39.187 に答える
1

言及された最初のオプションは、最も柔軟で再利用可能なものです。最初のアプローチでは、基本的に必要なすべてのケースをカバーできますが、以下で説明するいくつかの短所があります。

2 番目と 3 番目のオプションの方が読みやすく、これもテストを作成する際の重要な要素です。さらに、実際にテストされているもの、つまり「Foo」と「Bar」がそのシナリオ/機能で行うように見える重要な違いに焦点を当てているようです。そして、それはテストを書くときにも好まれます。

一般に、Cucumber のテストを作成することは、岩と困難な場所の間に身を置くようなものです。開発者はキュウリの手順を再利用したり、再利用したりして、シナリオの理解と維持が困難になる傾向があることに気付きました。2 番目のアプローチでは、ステップの定義に多くの作業が必要になりますが、シナリオはより簡潔で読みやすくなります... しかし、シナリオを作成するのにより多くの時間が必要になるだけでなく、大きなステップ定義ベースが生成されるため、保守が困難になる可能性があります。

本当に bddに Cucumber が必要な場合は、2 番目のオプションを選択することをお勧めします。ボンネットの下でまたは同様のものを使用FactoryGirlして、汎用オブジェクトを作成し、一度に必要なものだけを上書きするようにしてください。

これが役に立つことを願っています。

于 2012-04-16T15:46:54.380 に答える