6

webapp の単体テストを書いています。私のテスト ケースの多くは、同じボイラープレートを共有しています。たとえば、カートからアイテムを削除するテストとカート内のアイテムの数量を更新するテストはどちらも、製品ページに移動し、製品を検索してカートに追加することから始まります。

このような重複したコードは、何らかの方法で単体テストから除外する必要がありますか? 関数を書くべきadd_item_to_cartですか？しかし、別のテストtest_add_to_cartがあります。これは基本的に、カートに追加するというこの複製されたボイラープレートのみで構成されています。

各テストを独立させる必要があるため、単体テストは本質的に DRY ではありませんか?

4

3 に答える 3

3

単体テストは、1 つのことだけをテストすることになっています。「製品ページに移動し、製品を検索し、カートに追加する」ことから始まるテスト (これは 3 つの異なることです) は、単体テストのようには聞こえませんが、統合テストです。したがって、実際にはここでビルドする 2 つの異なるテストがあると思われます。

Cucumberまたは同様のものでの統合テストは、一連のステップで構成されている必要があります。

When I navigate to the products page
 And I search for a product
 And I add it to the cart

各ステップを 1 回定義して複数回使用できるため、DRY で優れたものになります。

一方、単体テストでは、必要なすべてのセットアップをスタブ化し、関心のある 1 つのことだけをテストする必要があります。

before
  stub(cart)
  stub(product)
  click on "X" for item in cart
it should...
  expect(cart not to contain item)
  expect(product count to be updated)

これが非常に複雑で、多くのスタブが含まれていることが判明した場合は、コードがモジュール化されていないことを示しています。解決策は、後でテストを追加するのではなく、TDD を使用して最初にテストを作成することです。

于 2012-04-11T04:41:37.997 に答える
2

共通コードを少なくとも関数にリファクタリングし、起動時にこの関数を呼び出します。繰り返されるセットアップコード（他の場所でテストする必要があります）ではなく、テストに固有のコードをテストする必要があります

于 2012-04-11T04:39:02.000 に答える
1

他のコードと同じ原則をテストに適用する必要があります。

例を考えてみると、テストを壊す何かを変更します。テスト コードを 1 か所で更新しますか、それとも各テストで更新しますか?

答えは明らかだと思います。

于 2012-04-11T04:32:40.797 に答える