仕様書がない時の結合テストのための単体テストの方法

単体テストには、
（１）ソースコードをブレークポイントでとめて、値を設定して全ルート通ることを目視で確認する
　　　→gdb等を使う

（２）外部から適当な値を設定することによって、コードカバレッジによって、全ルート通過した
　ことをツールで確認する
　　　→djunitなど、コードカバレッジツールを使う

の２通りが現在ある。

仕様書が一切ないでテストしろということがあるが、
この場合、（１）の単体テストでは、単体の品質レベルの保証ができない。
（プログラマが仕様を間違えていたとしても、仕様書がないから
　　　仕様書→ソースコード間が間違えているのか：単体テストで保証
　　　そもそも仕様が間違えているのか　　　　　：単体テストでは気づかないかも
　が、確認できない
　仕様書が有る場合、仕様書とソースコードが一致していれば、ソースコードを
　全ケース確かめることによって、仕様書→コード間には、間違いが無いことは
　確認できる）

ということもあるけど、結合テストの立場からも、（２）のテストを行うとおもう。

---

というのは、結合テストも仕様書がない場合、
全ケースをあぶりださないといけない。
このとき、全ケースとは、全出力ケースと考えられる。
この全出力ケースとは、同値条件分割にほかならない。

なぜ、同値条件に分割されるのかというと、
プログラム内部で、同値ごとに「分岐」しているからにほかならない。

つまり、
すべての分岐を追えれば、
　　その結果、そべての同値条件が明らかと成るので、
　　その同値条件を作り出す入力値（も単体テストで分かっているはず）を使って、
　　すべての結合テスト条件を作り出せる
可能性がある（あくまでも可能性だけど・・・DBの値を返している場合とかもあるので）

すべての分岐を追う＝カバレッジ１００％ということなわけ。

なので、（２）のテストを行うほうが、結合テストを進める上でも有利になる。

---

ちなみに、（２）のコードカバレッジをあげるには、
入力値の境界値テストの全組み合わせをやればよい・・・
・・・ことになるけど、これは物理的に無理なので、
実際は、ペアワイズか直交表を使う