さて、どうやってモジュールテストをしよう？使ってる言語がJavaやC++なら簡単だ。マトモなプログラマなら、クラスが他のいろんなクラスにべたべたに依存しているなんて気持ち悪い事はしないからね。依存している他のクラスのモックを作って、テスト対象のメソッドをいろいろ叩いてみれば良い。モックからエラーを返せるようにするのも忘れずにね。
Ｃ言語だと、ついついモジュールの境界が曖昧になる。そうなると、他のモジュールの依存も知らない間に増えているだろう。そうなると、モジュールをテストするには膨大な時間をかけて大量のモックを作るか、テスト対象のモジュールに手を入れてテスト可能な形に編集してからテストすることになる。前者だと余りにも時間がかかりすぎる（効率＝品質を忘れるな！）し、後者だと手の入れ方が大きいと、その部分にバグが隠れる可能性が出てくる。
この問題の解は、きちんとモジュール分けする事だ。当たり前の事しか言えなくてゴメンね。でも、テスト容易性(testability)は、現代のプログラムにとって最重要な品質なんだ。
Ｃ言語でプログラムを書くときも、モジュールの名前とそのモジュールが扱う範囲・扱わない範囲をはっきり決めて、その境界線でモジュールを切り出せるようにしよう。
特殊なインタフェースを使う場合は、そのインタフェースにマップされる標準の形のインタフェース（＝関数）を用意しよう。実際に実行するときは特殊インタフェースから関数をマップするだけのラッパを通して、テストするときは直接関数を叩く。逆に他のモジュールに特殊なインタフェースを通して通信しているときは、その特殊なインタフェースをラップする関数を作って、実際に実行するときはその関数経由で特殊インタフェースを使用する。テストするときには、そのラップ関数をモックにすげかえるんだ。
まとめ：
プログラムテストは、テスト対象の粒度が大切だ。「この程度の大きさならまずバグはないだろう」というような粒度でテストをしても時間の無駄。「この程度の大きさならバグが隠れてるかもしれない」という粒度でテストしよう。
