そのようなテストが存在する正当な理由がありますか?
5 に答える
一部のクラスはtoString
、ユーザーが読み取り可能な情報文字列以上のものを使用します。例はとStringBuilder
ですStringWriter
。このような場合は、もちろん、他のビジネス価値のある方法と同じように、この方法をテストすることをお勧めします。
一般的な場合でも、信頼性についてスモークテストtoString
を行うことをお勧めします(例外はスローされません)。最後に必要なのは、実装が不適切なためにコードを爆破するログステートメントtoString
です。それは私に何度か起こりました、そしてあなたがソースコードで呼び出しさえ見ないので、結果として生じるバグは最も厄介な種類toString
です—それは暗黙のうちにログステートメントの中に埋もれています。
問題は、toString()をテストする必要はないということですが、toString()の結果は気になりますか?何かに使われていますか?もしそうなら、はい、それをテストします。
メソッドが実際の何かに使用される場合は、それをテストします。
明らかな答えは「いいえ、それは時間の無駄です」です。ただし、多くのクラスでは、まず最初に値ラッパーを使用して、toStringをオーバーロードし、org.package.ClassName@2be2befaよりも多くの情報を提供する必要があります。
したがって、toStringの試用テストは次のとおりです。
@Test
public final void testToString() {
assertFalse(new MyClass().toString().contains("@"));
}
また、少なくとも悪くないテストの収束性も向上します。
メソッドの結果が重要な場合は、テストする必要があります。そうでない場合は、無視してかまいません。
私は一般的なアドバイスに反対し、toStringメソッドをテストすることは間違いなくその場所があると言います。特にデバッグまたはトレースレベルのログをオンにした場合、私がログに取り組んでいるアプリケーションはたくさんあります。バグを特定するためにログに依存していて、一部の開発者がtoStringメソッドの再生成を忘れたために、POJOの一部のフィールドが存在しない場合、これは大きな後退です。
問題は、toStringメソッドは固定形式ではなく、テストするための明確な方法でもないため、テストするのが非常に難しいことです。自分でテストを書くのではなく、ToStringVerifierなどのライブラリを使用することをお勧めします
@Test
public void testToString()
{
ToStringVerifier.forClass(User.class).verify();
}