「Test Driven Development for Embedded C」読書会第1回をやりました #tdd #tdd4ec

「Test Driven Development for Embedded C」読書会第1回をやりました。


そもそものきっかけは、2011年の「TDD Boot Camp 東京 for C++」というイベントです。これは組み込みやゲーム業界でC/C++の開発をやっているエンジニアがTDDを実践的に演習するというイベント。

その時に私がポジションペーパーに「Test Driven Development for Embedded Cの読書会をやりたい」と書いたところ、2名が名乗りを上げくれたのでやってみようとなりました。Twitterで呼びかけたところ、10名のエンジニアが参加を表明してくれて、それなりの規模の会になりました。

参加者のモチベーションは？

参加者は、複合機、医療機器、通信機器、家電などの組み込みソフトウェアを開発しているソフトウェアエンジニアです。皆それぞれプロジェクトの中で、レガシーコード（テストコードのない製品コード）を大量に抱えていて、いつも開発時間の大半をデバッグ時間に費やすという不毛な状況に追い込まれているようです。

そのような状況に対して、どうにかしてデバッグ時間を減らすために、不具合を早期に見つけるために、解決策の1つとしてTDDを使えないかと考えていました。

今回読んだ内容

第1回の今回は、第1章「Test Driven Development」、第2章「Test Driving Tools and Conventions」、第3章「Starting a C Module」をやりました。

第1章ではTDDをやる目的、TDDとは何か、TDDをやることで得られる恩恵は何か？を書いていました。
TDDは設計手段の1つとのことで、TDDの目的の1つとして設計改善があることは挙げられます。ただ、私は最大の目的は迅速にテスト結果のフィードバックを受けることで、即場に間違いを見つけること、バグを未然に防ぐことだと思いました。この点は、皆のやりたいことと一致していると思いました。

第2章では、この書籍で扱うテスティングフレームワークの使い方を紹介していました。C向けのUnity、C/C++向けのCppuTestの使い方が紹介されていました。
googletestと同様にCppuTestは自動的にTestRunnerにテストを追加する機能もあり、TDDにはもってこいのツールだと思いました。また、C++の枯れた仕様しか使っていないとのことで、古いコンパイラを使っている人にも安心して使えるツールです。
Unityは単体ではTestRunnerに自動的にテストを追加する機能はないそうですが、Rubyスクリプトでそれを代替しているようです。

第3章では、LEDのドライバソフトを題材に本格的にTDDをやって行く手順について紹介されています。
この章の中では、組み込みの中でのDevendency Injectionのやり方として、物理的なLEDドライバのアドレスを実行時に与えるというやり方を紹介していました。実行時に物理アドレスを与える方法を取ることで、ハードウェアとソフトウェアが分離され、ハードウェアがない状態でもテストできるというメリットが得られるようです。

分からなったこと

分からないなと思ったことが2つありました。
まず1つ目は、第3章のLEDドライバの例はシンプルだからアドレスを渡すみたいな設計にできるんだということです。実際に複雑な例であれば、アドレスを書き換えることによって、別のハードウェアのステータスが変わって・・・という依存関係が複雑になる問題があるので、そういう設計にはしないよねとのこと。

おそらくは、複雑なハードウェアの相互作用、あるいは複雑なタイミングの問題などを全て再現することなく、テストしたいところだけ取り上げてテストできるようにしたりするか（いや、どうするのか分かりませんよ？）。

あるいは、もっとも底辺なレベルのテストをTDDでやらずに、もう1段上のレイヤー、ハードウェアを抽象化している部分のテストをメインにやるのではないかということ。こちらは、全てをTDDしないので網羅的ではないですが、ポイントを絞ってテストすることで、実機を使ったデバッグに専念できるようにする効果はあると思います。

2つ目はレガシーコードが大量にあるシステムに対して、どうやってTDDをやっていくのかという問題。テストを動かすまでの準備が巨大であれば巨大であるほど、最初にTDDをやるモチベーションが下がっています。現場で実戦するなら、初期コストを抑えながら、徐々にTDDを導入する方法が必要です。
どうやらレガシーコードとの戦い方は13章に書いているらしいとのことで、このあたりの考え方は後半解消できるかもしれません。

第1回を終えて

当たり前ですが、第1回では我々の疑問に対する答えは部分的にしか解消できませんでした。しかし、共通した問題意識を持っているメンバーがそろうことができたのが今日の成果だと思います。
この会を重ねていくことで、現実とどう折り合いをつけていくか、何かしらの解を出せるのではと思います。

まず、この会のきっかけを作ってくれた「TDD Boot Camp 東京 for C++」の主催者の皆さんや、「Test Driven Development for Embedded C」の著者James W. Grenning氏には感謝したいです。

さて、主催者として参加者が満足できるような会にしていきます :)