Test-Driven Development for Embedded C 読書会に参加しました。

今年2月より始まった、Test-Driven Development for Embedded C（以下TDD for EC）の読書会が、今月始めに、めでたく最終回を迎えました。 全8回（うち1回は体調不良のため欠席）、10人前後のメンバーで、1年弱ほど続けてきました。

きっかけとモチベーション

読書会を知ったのは、Twitter上でした。フォローしていた方が呟かれていたのですが、TDD関連でその方を知り、フォローしたので、TDDについて追いかけていたことがきっかけでしょう。

TDDについて興味を持った理由はいくつかあります。

1. テスト自体への興味

私は、昨年2011年度卒として組み込み系プログラマになりました。プログラムの柔軟性や堅牢性については学生時代比較的意識していたのですが、テスト手法については、殆ど知識が なく、体系的な知識が欲しかったのです（これは現在進行形）

2. 開発スタイルへの疑問

実装して動かすまでのオーバーヘッドがかかりすぎることに悩んでいました。私が従事している開発は、基本的にモジュール単体での動作確認ができないため、他のモジュールと結合していない 部分の修正であっても、全モジュールをリンクしたプロダクトの状態で動作確認を行う必要があります。結果として、

• ほんの一行変えただけでも、ビルドに5分以上かかる
• ユースケースレベルの動作確認しか出来ない（単体動作用の仕組み一応はある）
• コーディング中に誤りがあっても、原因を検出しにくい

等、開発環境としては厳しいことになっています。（私自身が、まず動かしてみて、修正していくというスタイルだったため尚更）

もっとテストしやすくて、もっと実装しやすくする方法があるはずだ、と、WEBを探し回っていたところ、出会ったのがTDDであり、『TDD for EC』でした。

書籍について

TDD for ECは、C言語を用いた組み込みソフトを、TDDによって開発するためのノウハウが記載されている本です。

Test-Driven Development for Embedded C (Pragmatic Programmers)

内容としては、TDDの紹介から、利用するTestingフレームワークの紹介、C言語を用いた組み込み向けTDDの例、TDDで重要となる概念の説明（Test double, Mock等）と、TDDについて、網羅的に 説明しつつ、テストしやすい設計や、レガシーコードへの取り組みなど、TDDから一歩踏み込んだ内容になっています。 C言語に特化していますが、TDDの解説書としても、遜色ないと思われます（他の本を読み込んでいないのではっきりと断言できない）

導入部のコードの例が丁寧に書かれているのもTDD初心者にはありがたかったです。1ステップごとのコードが提示されているので、写経しながら、TDDのサイクルの感覚が分かりました。

また、私としては、Chapter 11. SOLID, Flexible, and Testable Designsで展開された、OOPの重要な概念であるSOLID原則を、PureなC言語で実装する方法がとても刺激的でした。 非オブジェクト指向言語であるC言語であっても、良い設計原則として、オブジェクト指向での原理原則が適用できるはずだと、これまで考えていたのですが、実際にどう適用するか、 私の中で回答がなかったのです。制約はあるものの、今回明快な回答が得られ、私の中の「良い設計」に対する認識が深まりました。

読書会に参加して得られたもの

本を読み得られたものは前節に書きましたので、読書会で副次的に得られたものについて書きます。

1. 社外のエンジニアと話ができた

読書会には、組み込みソフトを開発されているソフトエンジニアの方々が参加されました。

• 職場の環境
• 開発のスタイル
• 最近の技術動向
• 組み込み業界あるある

など、いろいろお話ができたのが良かったです。組み込み系の話は、WEB上では、あまり見聞きする機会がないので、とても興味深かったです。

同じ組み込みと言っても、開発の方法が一つではないし、環境も違うのですね（私の職場ほど旧態依然としているのは珍しいのか？）

2. 英文を読む習慣ができた

学生時代には、英語の論文などを読む機会もありましたが、就職してからは、殆ど英文を読む機会がありませんでした。今回、読書会に参加し、ある程度習慣化できたと思います。 今度久しぶりにTOEICでも受験してみようかと思います。

終わりに

私自身は、組み込み系ソフトと自動化テストは、本来相性が良いはずであると考えています。 組み込みソフトは、基本的にハードと仕様が変わらない限り、派生開発として、既存のソフトを利用します（場合によっては十年単位で）。
加えて、最近は出荷後も、ソフト改修やOSアップデートなどで、継続的に開発を行う必要があるケースも多く、自動化テストや、それを用いたCIなど 簡易に弊害確認が行える仕組みは本来とてもニーズがあるもののハズです。

ただ、現状、すでに動くソフトがあり、修正後の動作確認も人力で賄えるレベルであり、レガシーコードへの、自動化テストの導入には、かなりのコストが かかるため、主流にはなっていないようです。

ですが、組み込みソフトが大規模化し、メンテナンスの比重が高まっている（そしてメーカーに人力でのテストを行うための体力がなくなってきている）現在、 TDDを含めた、自動化テストのムーブメントは組み込み業界でも無視できないようになってきているのではないでしょうか。