36

単体テストでは、セットアップメソッドを使用してテストに必要なオブジェクトを作成します。

これらのセットアップメソッドでは、アサーションを使用するのが好きです。これらのオブジェクトに表示する値を知っており、アサーションを介してその知識を文書化するのが好きです。

スタックオーバーフローで他のユニットテストを呼び出すユニットテストに関する最近の投稿では、ユニットテストは他のテストを呼び出すべきではないという一般的な感覚があります：その質問への答えは、テストケースが行うようにセットアップをリファクタリングする必要があるようですお互いに依存していません。

ただし、「assertsを使用したセットアップ」と他の単体テストを呼び出す単体テストには大きな違いはありません。

したがって、私の質問：セットアップメソッドにアサーションを含めるのは良い習慣ですか？

編集：

答えは次のようになります。これは一般的には良い習慣ではありません。セットアップ結果をテストする必要がある場合は、アサーションを使用して別のテストメソッドを追加することをお勧めします（私がチェックした答え）。意図を文書化するために、Javaアサートの使用を検討してください。

4

5 に答える 5

20

結果を確認するためのセットアップでのアサーションの代わりに、単純なテストを使用しました（他のテスト方法に沿ったテスト方法ですが、最初のテスト方法として位置付けられています）。

私はいくつかの利点を見てきました：

  • 読みやすくするために、セットアップは短く、焦点を絞っています。
  • アサーションは1回だけ実行されるため、より効率的です。

使用法と議論 ：

たとえば、メソッドにtestSetup（）という名前を付けます。

これを使用するには、そのクラスにいくつかのテストエラーがある場合、testSetup（）にエラーがある場合、他のエラーを気にする必要がないことを知っています。最初にこれを修正する必要があります。

誰かがこれに悩まされていて、この依存関係を明示的にしたい場合は、setup（）メソッドでtestSetup（）を呼び出すことができます。しかし、私はそれが重要だとは思いません。私のポイントは、JUnitでは、残りのテストですでに同様の何かを持つことができるということです。

  1. ローカルコードをテストするいくつかのテスト、
  2. また、前のテストと同じコードを間接的に呼び出す、よりグローバルなコードを呼び出すテストもあります。

両方が失敗したテスト結果を読むときは、テストではなく、呼び出されているコードにあるこの依存関係をすでに処理する必要があります。最初に単純なテストを修正してから、グローバルテストを再実行して、それでも失敗するかどうかを確認する必要があります。これが、前に説明した暗黙の依存関係に悩まされない理由です。

于 2009-09-03T08:56:24.303 に答える
11

Setup/TearDownメソッドにアサーションを含めることはお勧めできません。一部のテストロジックがテストメソッドに含まれていないことをユーザーが「理解」する必要がある場合は、テストが読みにくくなります。目的以外の目的でセットアップ/ティアダウン方法を使用する以外に選択肢がない場合があります。

この質問にはもっと大きな問題があります。別のテストを呼び出すテストです。これは、テストの問題の匂いです。各テストはコードの特定の側面をテストする必要があり、その中には1つまたは2つのアサーションのみが含まれている必要があります。したがって、テストが別のテストを呼び出す場合、そのテストでテストするものが多すぎる可能性があります。詳細については、以下を参照してください。単体テスト：1つのテスト、1つのアサーション-なぜ機能するのか

于 2009-09-03T07:53:59.010 に答える
10

それらは異なるシナリオです。類似性はわかりません。

セットアップメソッドには、フィクスチャ内の（理想的には）すべてのテストに共通のコードが含まれている必要があります。そのため、残りのテストコードを実行する前に特定のことが真でなければならない場合、テストセットアップメソッドにアサートを配置することに本質的に問題はありません。セットアップはテストの拡張です。それは全体としてテストの一部です。アサーションが作動すると、人々はどの前提条件が失敗したかを発見します。

一方、セットアップが複雑で、正しいと主張する必要があると感じる場合は、警告サインである可能性があります。さらに、すべてのテストでセットアップの完全な出力が必要ない場合は、フィクスチャの凝集度が低く、シナリオに基づいて分割したり、リファクタリングしたりする必要があることを示しています。

これが原因の1つとして、セットアップメソッドを使用しない傾向があります。可能な場合は、プライベートファクトリメソッドなどを使用して設定します。これにより、テストが読みやすくなり、混乱が回避されます。これが実用的でない場合もありますが（たとえば、密結合のクラスでの作業や統合テストの作成時）、私のテストの大部分では、これでうまくいきます。

于 2009-09-03T07:47:33.110 に答える
4

あなたの心に従ってください/決定を点滅させます。Setupメソッド内のアサートは、意図を文書化できます。読みやすさの向上。だから個人的に私はこれであなたをバックアップします。
他のテストを呼び出すテストとは異なります-これは悪いことです。テスト分離なし。テストは、別のテストの結果に影響を与えるべきではありません。

これは頻繁なユースケースではありませんが、セットアップメソッド内でAssertsを使用して、テストセットアップが意図したとおりに行われていないかどうかを確認できる場合があります。通常、自分で作成していないコンポーネントを扱っている場合。「セットアップに失敗しました！」というアサーションの失敗 [エラー]タブで-失敗したテストの束を調べる代わりに、セットアップコードにすばやくゾーンインするのに役立ちます。

セットアップが失敗すると、通常、そのフィクスチャ内のすべてのテストが失敗するはずです。これは、鼻がすぐに拾うはずの匂いです。「すべてのテストが失敗したということは、通常、セットアップが壊れたことを意味します」したがって、アサーションは必ずしも必要ではありません。それは実用的であると言われています、あなたの特定の文脈を見て、そして「味に加える」。

于 2009-09-03T08:19:12.193 に答える
3

このようなことが必要な場合は、JUnitではなくJavaのアサートを使用します。たとえば、他のユーティリティクラスを使用してテストデータを設定する場合。

byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;

失敗すると、「システムはこのテストを実行しようとする状態にさえありません」という意味があります。

于 2009-09-03T09:26:37.930 に答える