「それ、どうやってテストするの？」（続）
http://d.hatena.ne.jp/JavaBlack/20070808/p1
ほとんどのまともなプログラマーなら，無意識のうちにそういうテスト可能／デバッグ可能なコードを書くことを心がけている．テスト／デバッグ不可能なコードを書く人というのは，まともなプログラマとは思えない．
JavaBlackさんは「自分で何を作るか考えてコードを書く人」について語っているとみた。完成像を理解しているプログラマなら、「コードのあるべき姿」もわかっているからテスト機械化のハードルも低いだろう。
問題なのは下記のような分業状況。
- 何を作るかは考えるけどコードは書かない人（別名：設計担当）
- 何を作るか考えることは許されず、言われたとおりにコードを書く人（別名：開発担当）
設計担当はコードを書くことはない。書くのは設計書なる文書だけ。「その設計書、どうやってテストするの？」と聞いてみるがよい。答えに窮するか、「作ったものをテストする」と答えるかのどちらかのはずだ。
設計書は動作しないから、設計書をもとに開発したコードをテストするしかない。
でも、「設計書」を書く人はコードの細かいところまでは考えていないから[*1]、細かいところのテストは開発者に任されることになる。
ここが問題。
- 設計者が考慮していない「細かいところ」のテストは「何を持ってテスト成功」とするのか。
- それを開発者が勝手に決めちゃっていいのか？
- 開発者が決めたテストの妥当性について誰が検証責任を持つのか？
- テスト結果が設計者の意図するものと異なる場合は開発者の責任なのか？ 設計者の責任なのか？
などなどをまじめに考えると疲れちゃうから、常識的には開発者は設計者が提示した範囲の仕事しかしなくなる。
古き良き時代の浪花節的日本のゼネコン構造では、設計業者と開発業者の間に「阿吽の呼吸」があった[*2]からうまく回ったこともあったけど、今の世代ではあまり期待できない。ドライなオフショア業者は「言われたことしかやらない」の典型であろう。
設計と開発を分業することによって
- どこまでテストしたかわからない
- どこまでテストすればよいのかもわからない
コードができてくるのである。それをどうやってテストするの？
