ちょっと全然別のことを考えていたときに、なぜか、思いついたので。。
メモメモ。
よく、開発のときに、単体テストを線表上はあるけど、時間がなくて省略することがある。
このとき、省略しても、うまくいくケースとうまくいかないケースが、経験的にある。
（単純に、人の問題とか、そういうのではない気もする）。
この条件って、なに？っていうのが、大体分かっているんだけど、それって、理論的に
説明できてなかったんだけど、いま、「そうだよね」と思ったので。。メモ。
もともと、単体テストを省略しないでやろうと思った時点では、
単体テストで
・単体テストの仕様書（どのように行うか）
・とその結果（エビデンスを含む）
を提出するつもりでいる。
さて、最近、プログラムを開発するときは、昔のように、
・コーディングシートに書いて
・パンチして
・一気にコンパイルして確認する
ということは、まずしない。
ふつう、
・トップダウンにつくっていって、
・ダミーモジュール（スタブ）を作成し
・ダミーモジュールを呼び出す形で確認を取り
・OKだったら、今度はそのダミーモジュールを作っていく
というように、テストファーストの手法で、多分組んでいると思う。
この場合、コーディングが全部終わった時点で（JUNITを使っていれば、
ダミーモジュールがなくなって、すべて実装し、緑色になった時点で）、
テスト仕様書は１ページも書いていないけど、実質単体テストまで完了
している。
完了していないと、プログラムは、実装できないので。。
ところが、テスト仕様書とそのエビデンスはまったく書いていないので、
テストは、まったく、していないことになっている。
なので、ここから仕様書を書かなければならないが、しかし、ここで
書いてしまってもムダになる可能性は大きい。
というのも、この時点では結合テストをしていない。
結合テストの結果によっては、プログラムは変わり、そしたら、単体テスト
やりなおしになる。
ということは、先に結合をやって、安全なことを確かめたほうがいい。
ってなると、単体テストを省略し、結合を先にやったほうがいいことになる。
この場合、単体テストは省略しても、品質に問題ないことになる。
という場合、じゃあ、これが成立する条件は？と考えると
・トップダウンで作っていき、分からないところにスタブを入れていく
・で、トンドンスタブを奥ふかくまでつくり、スタブの部分がなくなるようにする
・すべてのテストはOKとなっている（JUNITで緑になる）
っていうことになると。。スタートの時点の問題になる。
初めの時点で、入力データと出力データに対するダミーデータがそろっていて、
そのダミーデータがすべてのケース分、存在すること。
まず、データがないとテストできないのでX
で、正常形だけあっても、異常系でおかしくなるかもしれないのでX
正常、異常、すべてのケース分の入出力データがあれば、それをもとに、テストファーストで
テストできる。
ここで問題なのは、この「正常、異常、すべてのケース分の入出力データ」を
確認しないといけないのは、構造設計レベルである（単体のプログラムではない。
単体プログラムはそれが呼び出されるプログラムとのインターフェースの整合性
まではわからない。コレが分かるのは、構造設計）。
つまりよく、プログラムの出来が悪いと、単体を作ってるプログラマが馬鹿だからとか
単体テストやってないからとかいったり、ITレベルで落ちると、単体テスト以下だろうとか
言う人が、非常に多くいるが、本質的な問題は、構造設計における、インターフェース設計の
甘さと事象の読みの甘さ、あと、PG担当者に対するPGの進め方の指示ミスであることが多い。
このように、本質的な問題は解決されず、PG側に責任転嫁し、まわりもこの事象を
見抜けないため、この問題は何度も繰り返し、起こっている。
っていうことは、分かりきっていることなんで、どうでもいいんだけど、
せっかく思いついたことがまとまったんで、一応書いておいて見た。
アクセス
トータル
ランキング
