java - junit:テストケースを開発するためのベストプラクティス?

Question

テクノロジー: Junit 最新バージョン アプリケーションはビジネス指向

テスト ケースにハード コーディングされたデータを使用する人もいれば、プロパティ ファイルや xml ファイルを使用する人もいます。私の知識によると、xmlは他の2つよりも優れています。業界で使用されているより良いアプローチはありますか。テスト ケースを開発するためのベスト プラクティスを提案してください。

Answer 1

テスト内のデータ表現とテスト対象の関数に渡されるデータとの間のマッピングは、可能な限り透過的であることが重要です。ハードコードされたデータは、データが少なく、ソースで簡単に観察できる場合はまったく問題ありません。テスト ケースを理解するために開いておく必要があるウィンドウが少なければ少ないほど、良い結果が得られます。

XML は、ネストされたツリー状のデータに最適ですが、少し冗長です。YAML もこれに適している場合があります。フラットなデータの場合、プロパティと行編成のファイルのみで問題ありません。

あらゆる点で他のすべてよりも優れている単一の形式はありません。特定のテスト スイート/サブジェクト エリアに対して、最も簡単で自然な方法を選択してください。最も自然な形式を処理するための努力は、より多くのテスト ケースを迅速に生成する必要がある場合や、回帰を調査する場合に有効です。たとえば、私たちのプロジェクト (非常に大規模) では、テスト ケースのデータの読み書きを簡単にするために、いくつかのデータ表現を考案し、(単純な) カスタム パーサーを作成する必要がありました。

Answer 2

私はテストを速くてシンプルに保つようにしたいと思います。テストの実行速度が速いほど、ビルドに追加できるテストの数が多くなります。

xmlの欠点：解析は非常にコストがかかり、DOMからも値を読み取ります。表形式のデータには、ある種のCSV形式のフラットファイルを使用します。キー/値データの場合、単純なプロパティファイルで十分です。

JUnitでは、単体テストレベルにあり、パブリックインターフェイスが仕様に従って実装されているかどうか、およびすべての可能な入力に対して定義された方法で動作するかどうかを知りたいと考えています。したがって、通常は変更されないため、テストメソッドにテスト値をハードコーディングします（テストクラスの外部で値を編集する必要はありません）。

Answer 3

ベストプラクティスはないと思います。特定の問題領域と、実行する必要があるテストの種類に最適なものを使用することをお勧めします。コード化する必要があるテストに、本質的に多数の異なる入力を使用したメソッドの呼び出しが含まれる場合は、データ ドリブン アプローチ (プロパティ ファイル、XML、またはその他のものを使用) をお勧めします。そうでない場合、それは悪い考えです。

注意すべきことの 1 つは、テストを適切にコーディングできるように、複雑なインフラストラクチャの作成に多くの時間を費やしていることです。