unit-testing - ユニットテストロジック、統合テストデータ

Question

ここでユニットテストの価値について話し合いました：

統合テストだけを使用できるのに、なぜ単体テストを気にする必要があるのですか？

しかし、それから推測できるのは、単体テストは目立たないロジックメソッドに適しているということですが、データを操作するときは、統合テストにフォールバックする必要があります。

私が抱えている問題は、実際のLOBアプリケーションにあります。それらが行うことの99％はデータの操作です。つまり、一般的なアプリケーションの1％だけが単体テストに適しているということですか？

Answer 1

統合テストは、インターフェイスが期待どおりの結果を返しているかどうかをテストするだけです。ユニットテストは非常に具体的で、内部が機能していることを確認するための非常に小さなテストです。これらは、統合テストで見つけるのが非常に難しいコードの暗い領域を明らかにするのに役立ちます。統合テストは、テスト対象のコンポーネントを変更または再利用することが決して許可されていない場合に最適です。

単体テストにより、現在使用されていない可能性のあるコードの機能、または誤動作や失敗の原因となる奇妙な状況にさらされる可能性のあるコードの機能に自信が持てます。これは、車全体を悪用して故障させるのではなく、車の個々のギアをストレステストするようなものです。

データ操作に関して、プロセスで単体テストを行うのが難しい場合は、十分にモジュール化されていないことを示しているはずです。

Answer 2

データが含まれる場合でも、単体テストを使用します。たとえば、Webアプリで応答ハンドラーをテストする場合、ハンドラーをテストするために実際のajaxリクエストを起動する必要はありません。代わりに、いくつかの例のjsonを文字列に入れて、それをハンドラーに渡します。

ファイルからデータを読み取るアプリケーションを作成している場合、データ処理メソッドは、実際にファイルを逆シリアル化するコードとは完全に分離されます。したがって、この場合も、実際のデータをいくつか取得して、テスト対象のデータ処理メソッドに渡すことができます。

単体テストを使用すると、コードの設計にも情報が提供されることがわかります。これらの例では、データを処理するメソッド/クラスは、データを取得する方法とは完全に分離されています（つまり、分離されています）。

ちなみに、私はおそらくそこにもいくつかの統合/機能テストを投入するでしょうが、単体テストは1％の時間しか適用できないという考えには完全に同意しません。