単体テストのテストケースの考え方(あげかた)について

単体テストのテストケースの考え方(あげかた)について

最近、プログラム(java)をはじめたものです。
単体テストを行ううえで、
まず、テスト仕様書の作成を行う(正確にいえば詳細設計段階でやりますが…)と思いますが、
そのテストケースのあげかたはどういう着眼点であげればよいのでしょうか？

単体テストは、詳細設計に対してのテストだと思いますので、
基本的には、詳細設計で作成いたフローチャートの分岐をすべてのケース通るような仕様書を作成しています。

ただ、このやり方だと、問題があるような気がするのです。
たとえば、javaでMapを使用していて、
入力値が、値が固定のMap(例：1,2,3)に入っていればtrue、入っていなければfalseという処理があるとき、
フローチャートでは、trueかfalseかの２パターンしかなく、
実際のコードの記述もget(入力値)で、あるかないかだけ判断するため、２パターンです。
しかし、実際は、固定Mapの値1,2,3,とそれ以外という選択肢があるとおもうのですが、
こういう場合は、１、２、３、それ以外の４パターンのテストを行うべきでしょうか？
それとも、Mapにあるかないかだけの部分なので、trueの時とfalseの時の２パターンでいいのでしょうか？

No.1 ベストアンサー 回答者： nda23 回答日時： 2010/07/06 10:11

単体テストは仕様書に従うべきものです。

Mapが出てきたのは結果論であって、例えば、switch文とか
if文を連ねるやり方も（定数なら尚更）あり得る話です。
フローチャートにしてもYes/Noだけではなく、多分岐的な
書式もあります。
仕様書では「1、2、3はtrue、他はfalse」と書かれているなら、
「1、2、3、それ以外」の全パターンを通過しないといけません。

No.2 回答者： 0909union 回答日時： 2010/07/06 11:06

単体テストとはUTフェーズの事を指しているんですかね。

No1の方の回答が正統派の回答かと思います。

もし、テストをチームで行う場合、又、第三者テスト又はブラックボックステストが、後に控えていて、全体的に、テストがフェーズ管理されている場合、

全体的な中の、単体テストの位置づけを、プロジェクトリーダー及び第三者テスト又はブラックボックステスト管理者と話し合うべきです。

結局はスケジュールに集約されますが、仕様書が実装よりも前に書かれることが、そんなに多いか?　と言う事になり、仕様書が先に在る場合（モジュール単体の）、単体テスト＋入力値以外のテストをする事が、どれだけスケジュールに影響するか天秤にかける必要があります。

通常単体テストとは、０か１です。１つの入力に対して一つ回答を得るです。

ようは、後半のテストとの量と質のバランスです。

UTで発見されるべき事柄は、実は結構存在していて、後から考えるとUTで発見されていてもおかしくなかった。と言うのが多いはずです。しかし実際にはUTでは発見されない。

それは結果に対しての予測が甘いからです。

そのモジュールの使われ方が予測されていない所で起きていることが、最も多く、それがUTで発見されなければならないのか?　これは、あきらかにスケジュールの問題です。担当のコーダー又は、設計者が係わったテスト中での発見でよいかと。

一番多いのが、サニタジするときですね。だれが管理するんでしょうね。最後のブラックボックステストで分かる事は、「その文字が使われる事は予測しなかったの?」です。

でもモジュールのコーダーから言わせると、設計には問題ないし単体テストでも問題なかった。この問題が答えです。