単体テストユーティリティクラス

私たち全員が、さまざまなソースからの使用のために、静的メソッドのみを含むいくつかのユーティリティクラスを持っています。ここで、このコードのテストに向けて実行できる2つの方法があります。

アプローチ1：

ユーティリティクラス用に個別の単体テストを用意します。それらが呼び出されているところはどこでも、PowerMockなどのプロビジョニングが用意されているテストフレームワークを使用して相互作用を模擬します。これは基本的に、ユーティリティクラスをシステムの個別のコンポーネントとして扱い、個別にテストして保守する必要があります。

アプローチ2：

ユーティリティクラスの単体テストを記述しないでください。ただし、このユーティリティクラスと対話する他のコアクラス用に記述されたテストでは、その相互作用が発生します。これにより、このユーティリティクラスで記述されたコードがさまざまなユースケースに対して適切にテストされることが本質的に保証されます。何かが壊れた場合、他のコンポーネントのテストはそれをキャッチできるはずです。

どちらのアプローチが望ましいか、または他の方法でこれに取り組む方法があるかどうかについて、あなたの考えを共有してください。

「実用性」のクラスについては、大きな誤解があると思います。クラスを「静的」にしたからといって、それがユーティリティクラスになるわけではありません。静的ユーティリティクラスに依存関係がある場合（他の静的「ユーティリティ」クラスに現れる可能性があります）、副作用が発生するか、その動作が入力によって完全に制御できないため、ユーティリティクラスではありません。

真のユーティリティクラスは、入力に応じて出力が常に確定的であるため、モックする必要はありません。

ユニットテストとは、アプリケーションの小さな部分（ユニット）を分離してインスタンス化することです。これにより、そのユニット内のすべてのコードパスを（可能性として）テストできます。依存関係のモックはこの分離を実現します。ユーティリティクラスが分離を解除する場合、ユーティリティクラスは定義によって分離されることになっているため、これもユーティリティクラスではありません。

したがって、アプリケーションでは、ユーティリティクラスをモックしたり、モックしたりする必要はありません。モックする必要があると感じるクラスは、最初のクラスのインスタンス化可能なクラスに変換する必要があり、依存関係としてユニットに渡す必要があります（依存関係注入を参照）。これらの依存関係は簡単にモックできるため、ユニットを個別にテストできます。

私の意見では、文字列分割などの静的ユーティリティメソッドへの依存関係を模擬するのはばかげています。

はい、splitterメソッドが間違っていると、文字列分割に関係しないメソッドのテストで偽のエラーが発生する可能性があります。しかし、それがテストスイートのポイントではありません。テストスイートは100％成功する必要があります。そうでない場合は、問題のある部分を修正し、100％成功するまで繰り返します。文字列ユーティリティクラスが壊れてしまった場合、それはすぐにテストの失敗の原因とすべきである文字列の機能について。その機能を修正すると、すべての失敗が消えるので、誤って失敗したテストケースを確認する必要さえありません。

つまり、はい、ユーティリティメソッドのテストを記述します。いいえ、他のテストから切り離そうとしないでください。単純なユーティリティ関数が、独自のテストで検証されたとおりに正しく機能すると仮定します。これ以上何をしても、何の利益も得られません。