組み込みTDDにおける関数ポインタ置換とモックオブジェクトの導入について

先週末、組み込みTDD読書会第5回をやりました。
内容は以下の輪読およびディスカッション。

• 第9章 「Runtime-Bounded Test Doubles」
• 第10章「The Mock Object」

#当日のやり取りはtogetterにもまとめていますので、そちらも参照ください。

第9章 「Runtime-Bounded Test Doubles」

C言語でプロダクトコードを実装する場合、依存先モジュールをTest Doublesに置換する方法として、プリプロセッサ、リンク、関数ポインタがあります。第8章で紹介されていたリンク時置換は実行時に関数を置き換えることができず、自由度は低いというデメリットがあります。テスト実行中に、あるときはプロダクトコード、またあるときはTest Doublesに置き換えたい場合は、第9章で紹介されている関数ポインタ置換が有効です。

ただし、ディスカッションの中で関数ポインタとプリプロセッサはコードの可読性を下げる副作用があり、多用しない方がいいという意見が挙がりました。そして、書籍内ではほとんどプリプロセッサ置換の話は出てこず、著者はプリプロセッサ置換はあまり好きじゃないのかもしれません。

第10章「The Mock Object」

第10章は、組み込み業界だとなじみの薄いモックオブジェクトについて。
題材は実在するフラッシュメモリのデバイスドライバです。フラッシュに限らず、デバイス入出力は以下の理由でハードウェアと統合する前にモックオブジェクトを使った品質を確保する手法が有効なのだそうです。

• 詳細なプロトコルに従って書き込み・読み出しをするテストは、通常のテスティングフレームワークでテストしづらい。
• 本物のデバイスではテストできないケースがある。（例）特に例外系などは再現できない場合がある。

10章の大半はC言語でモックオブジェクトを実装する方法について解説が割かれています。一方で、C++のモッキングライブラリCppUMockやC言語のモック生成ツールCMockなども紹介されています。

たいていの場合、モック自身が複雑になると思うので、解説を見る限りでは自作モックはモック自身のちゃんとしたテストが必要な印象を受けました。
#ライブラリの品質が保証されていればOK?

一般的に、デバイスの入出力をある程度共有化できるように作ると思うので、モックを作ったり、コストをかけて取り組む価値は出てくるのかなと思いました。

最後に業務系やWeb系でモックオブジェクトが流行っている理由について話が及びました。理由は簡単で、言語的制約がないためモッキングライブラリが整備され、モッキンぐライブラリが使いやすくなっているからではないかとのこと。

こういう点が組み込みTDDが、組み込みじゃないTDDとの違いで。言語制約を乗り越えるためのスキルや仕組み作りなしには、TDDの効果を出せないのかと思いました。