Test-Driven Development for Embedded C を読み始めた。

Test Driven Development for Embedded C (Pragmatic Programmers)

組み込みでTDDの本ということで興味を持ったので買ってみた。洋書の技術書を買ったのは初めて。

組み込みの仕事をやっていて、単体テストと呼んでいることはやっている(TDDじゃない)。
テストファーストではなく、実装後にテストコードを書いてる。テストコードはモジュール単位(デバイスドライバのAPI単位等)。
単体テストの実行環境は評価ボードとかエミュレータ上でやっている。
実装後にテストコードを書いているせいか、最初の実装の単体テストが終わったら、もうテストコードの実行をしなくなってしまう。何回か仕様変更や機能追加などをしたとき、単体テストやらないといかんなと思っても、テストコードのメンテをしてないのでテストコードの追加や修正が山ほどある。自分のせいなんだけど、これがすごくめんどくさい。

TDDはめんどくさくないだろうか。TDDは楽しいという話も聞くので、ちゃんとTDDやってみたいと思う。

この本で気になったこと。

• テストコードの実行環境はホスト？ターゲット？
• ユニットテストフレームワークはライブラリやメモリの少ないターゲット上で動くのか？
• Cでのスタブのスマートな作り方はないか？(#ifdef UNITTEST とか製品コードに入れたくない)

あと普通のTDDでもよくわからないことは多い。

• テストファーストにするメリット。テストしやすいきれいな設計にするために最初にインターフェイスをちゃんと考えろってこと？
• getterがないprivateなメンバ変数のチェックするテストはどうやるのか？例えば、ある通信フォーマットのバイト列を入力にして、それぞれのデータをメンバ変数に設定する関数のテストとか。

ケント・ベックのテスト駆動開発入門も読むべきか。あとレガシーコード改善ガイドも読んでおきたい。

英語は得意じゃないし洋書を前から順番に一字一句読んでいくことは苦痛になりそうなので、目次をみて興味ありそうなところから読んでいくことにする。

まずはざっと目次に目を通してみる。

最初にTDDの紹介の章があり、そのあと大きく四部にわかれている。

第一部はTDD始めてみよう、という話。
TDDツールにはUnityとCppUTestを使って、LEDドライバを例に実際にTDDをやってみる。
5章のEmbedded TDD Strategyはハードを絡めたTDDサイクルの話。一番気になるところ。
6章のYeah,but...はTDDする時間ないよ！とか、なんでテストコードを後から書いちゃいかんの？とかの疑問に応えてくれる話らしい。これも気になる。

第二部は主にスタブとかモックについて。Test Doubleという言葉を初めて知った。doubleには代役とか替え玉という意味があって、要するにスタブとかモックの意味だと思う。スタブとモックの違いも知らないけど。

第三部はリファクタリングとかレガシーコードをどうするかとかテストパターン、アンチパターンの話。

第四部は付録で、開発環境とかTDDツールのリファレンスなど。

まず5章から読んでいこう。
この本についてはまた感想など書いていこうと思う。