単体テストで引数がnullのパターンを実施する理由がわかりません

Question

単体テストで引数に正常系と異常系を設定してテストするテスト仕様書を今まで見てきました。
正常系は分かるのですが、引数にnullを設定する異常系のパターンを何故テストするのかが分かりません。
引数にnullを設定してヌルポが発生することを想定結果としているのですが、テストする意味があるのでしょうか？

Comments

[gentaro]

わからない理由を述べて欲しい。
何故不要だと思うのか。

[m.ts10806]

設計者に聞いてください。

[sigsegv]

異常系テスト全て不要と思ってるのか、
null のテストだけ不要と思ってるのか

[Zuishin]

> 引数にnullを設定してヌルポが発生することを確認

要るじゃないですか。

そもそも何のためにテストをするかわかってないとか？
まさかテスト対象の関数をいじらず全部通るテストを作ろうとしてるとか？

Answer 1

どんなメソッドかわからないので設計も含めた個人的に採用しているルールです。
ベースとなる考え方は引数がnullになりうるかどうかです。

下記のケースではnullチェックを行い独自に用意した例外をthrowし、テストも行います。

• ライブラリとして公開する場合
• 引数がユーザの入力によるものの場合
• 引数が他システムからのデータによるものの場合

下記のケースではnullチェックもせずテストも行いません。

• メソッドが使用される範囲が限定的かつ実装ミスでしか入らない場合

限定的とは何ぞやというところが迷いどころではありますが……。

テストコードであったとしてもNullPointerExceptionを想定するのは設計が怪しいように思います。
確認したいのは本当にNullPointerExceptionの発生ですか？
本当は独自の例外が発生する想定だったのにチェックの実装が漏れていた or 誤っていたとかじゃないですか？

Answer 2

そのモジュールのテストは、nullを受け付けるとどのような挙動になるのでしょうか？

NPEが発生するのが仕様であるなら、発生しない場合バグですよね？
それを確認しているのかもしれません。

前提として、引数がnullならNPEが必ず発生するのが当たり前というのがあるのかもしれませんが、
それは実装次第です。

ちなみに既回答にありますが、null渡してNPEが発生するのは設計・仕様がいけてないとは思います。
安全を重視するなら、そもそも例外投げない仕様・実装にするとか、
プロジェクト固有のRuntimeExceptionにまるめるなどが考えられます。

あとは質問者さんの疑問に思う通り、
いわゆるセッターゲッターを個別にテストしないのと同様に、
NPEが発生したら明らかにモジュールの利用方法がおかしいと判断するテストが不要な項目の可能性はあります。

Answer 3

何故災害に供えて避難訓練等するのでしょうか。
何故企業は製品に「子供が飲み込まないように」だとか「火に近づけないように」だとかの注意書きをするのでしょうか。
異常事態を想定内として対応出来るようにするためです。

オブジェクトを渡せるところには( @Nonnull 等無ければ？) null も指定できます。言語レベルではそれは『正常』です。
NullPointerException も仕様として存在するのですから発生するのは『正常』です。

「なら『異常』とは何か」となりますが、それは「想定外」のことであり、それこそ「バグ」 であり、それは「作った側の想定不足」です。
(バグの由来とされる「コンピュータ内に虫が入ってショート」を想定してプログラムを組むことが可能とは思えませんが^^;)

「書いた通りに動く」プログラムにおいて、その書き手であるプログラマは、そのプログラムの動作には責任があります。
だからこそテストするのであり、可能な限りの全てを「想定」し、『正常に』動作することを確認しておく必要があるのです。

Answer 4

そういうテストをやったことがないので、あくまで予想ですが、

・テストというよりも、異常によって起こりうる損害の確認。例えば、無条件にdelete文発行してないかとか。
・テスト工数の水増し。
・閾値テストの一環。

当たりでしょうか。

テスト観点は、プロジェクトによって異なるので、
疑問は、テストルールを決めてる責任者の方に聞いた方がよいとは思います。

Comments

[Zuishin]

異常という用語と閾値という用語が間違って使われているように読めます。

Answer 5

実装上その値を受入可能となっている時点で試験すべきものです。
NullPointerExceptionを個別で捕捉して想定の例外として処理する設計になっているなら尚更です。
余程の理由がない限り、カバレッジは100%にすることが基本です。

あとは設計者の意図やシステムの要件次第。