5

これらの行を含む単体テストがあるとします

assertNotNull(someVal);
assertNotEmpty(someVal);

これは明らかに someVal が null ではなく、何かが入力されていることを確認します。

問題は、最初の行が必要で、テストに何かを追加するかどうかです。2行目だけではなく、それがnullの場合、単体テストの失敗を示すnullポインター例外がスローされます（ただし、アサーションの失敗ではありません）。

このような単純な場合のベストプラクティスは何ですか?

4

4 に答える 4

5

NPEをテストの失敗と見なすべきではありません。実際には、nullではないと主張し、エラーメッセージを提供する必要があります。

assertNotNull(someVal, "Some descriptive message saying why value should not be null");

于 2012-10-25T12:50:30.530 に答える
4

場合によります。関数 myFunc をテストしているとしましょう。例外ではない場合に myFunc が null を返す場合、テストをより明確にすることができるため、結果が null ではなく正しい値であることを確認するのが合理的だと思います。

ただし、null が例外的なケースである場合、それをチェックすることは、テストで RuntimeException をキャッチすることに似ています。テストが乱雑になり、意図がわかりにくくなります。

于 2012-10-25T12:53:02.043 に答える
3

JUnitの障害とエラーには違いがあります。失敗は予期されるものであり（またはで明示的にテストされassertXXX()ますfail()）、エラーはそうではないものであり、通常は例外です。JUnitの失敗とエラーの違いは何ですか？を参照してください。。

あなたが電話する場合

assertNotNull(someVal);

次に、この値はnullであってはならないと言っており、具体的にそれをテストしています。NullPointerExceptionを発生させると、エラーを解釈する人は、テスト対象のコードが正しいかどうかわからないか、すべてのケースについて考えていません。

それは意図の問題です。他の人が指摘しているように、説明メッセージも追加することをお勧めします。

于 2012-10-25T12:54:21.983 に答える
2

私はassertNot()'s の大ファンではなく、より一般的には、SUT に発生する可能性のある予期しないことをテストします。

IMO オブジェクトの公称状態のみをテストする必要があります。特定の状況でが null になるのが正常な場合は、そのシナリオで実際に null であることを確認する専用のテスト メソッドを作成します。のように、テストの意図を明らかにする名前を選択します。空またはその他の値についても同じことを行います。someValsomeValShouldBeNullWhen...()

テストの例外メッセージを確認することで、予期しないことが SUT で発生することがわかります。これらの予期しないことのそれぞれを事前に予測して、テストに assertNots を詰め込むことではありません。

于 2012-10-25T13:18:34.577 に答える