はじめに

Amazon.co.jp: テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計

本記事は、上記書籍を使って学習を始める人が、環境構築で躓かないようにしたい、という主旨のシリーズ第1弾です。

私は組込みシステム開発をしており、C言語をメインに使っています。
この本に出合う前は、コードを修正するたび、クロスビルドして、ターゲットボードにバイナリをコピーして動作確認をしていました。ハードウェアはチーム人員に対して十分な量がないため、他のメンバーがハードウェアを使っているときは、動作確認できず、開発が滞ることも多かったです。

今年の2月に、この本に出会い、書かれていることを業務でも実践するようになりました。
結果として、私の開発スタイルがガラっと変わりました。デュアルターゲットのビルド環境を整え、ハードウェアがなくても、ホスト上でユニットテストベースの開発を行えるようになり、自動ユニットテストにより、ちょっとしたミスがすぐに見つかるようになりました。
自分の書いたコードの品質にも少しだけ自身が持てるようになってきました。

今や、新しく追加する機能は、全てTDDで開発し、既存箇所にも時間を見つけてテストを書き、容赦ないリファクタリングを続けています。
コードは改修を重ねるたびに、より読みやすく、良い設計に進化していると感じています。

本書では、テスティングフレームワークとして、UnityとCppUnitが紹介されています。
そのままやるのも芸がないと考えたのと、本書を勉強する上で後述する躓きがあったため、今回、googletestを使ってすぐに本書の勉強が始められるソースコードを公開することにしました。

ビルドツールにはAutotoolsを使っています。そのため、公開しているソースコードは、クロスコンパイラでそのままクロスビルドすることが可能です。
googletestは、インストールなしで動作するので、クロスビルドしたバイナリをターゲットボードにポンっと置けば、ターゲットボード上でユニットテストが動きます。

学習する上で躓いたこと

本書を読み進めながら、Unity, CppUnitを使って写経しようとしましたが、恥かしながら、環境構築で躓きました…。（何で躓いたか、もう忘れてしまったのですが、なんだかんだで1日くらい格闘していたと思います）
また、公開されているサンプルコードでは、ビルドスクリプトが（自分にとっては）複雑で、自分でちょっと拡張したい、ということが簡単にはできませんでした。
ちょっとしたことなのですが、学びたいこと以外のところで躓くと、学習意欲が削がれやすいです。

組込み業界入りたての人でも、自分でファイル追加して、写経できるような環境を考えて、作ってみました。

ソースコード

ソースコードは以下です。
https://github.com/tomoyuki-nakabayashi/TDDforEmbeddedC

4章終了時点のプロダクトコードとテストコードを公開しています。
git, gcc, autotoolsがインストールされていれば、1分以内にテストが実行できます。

本書を最初から写経したい方は、src/LedDriver.c, src/LedDriver.h, test/LedDriverTest.cppの中身を削除して下さい。

ソースファイルの追加

自分でソースファイルを追加して、色々試してみたい場合には、下記ファイルの該当箇所にファイル名を追加して下さい。
TDDforEmbeddedC/test/Makefile.am

test_sources = \
  TestMain.cpp \
  LedDriverTest.cpp
target_sources = \
  $(top_srcdir)/src/LedDriver.c
gtest_SOURCES = $(test_sources) $(target_sources)

テストダブルとmock

本書の7章以降では、テストダブルとmockの話が掲載されています。
残りの内容に関しても、写経を簡単に始められる環境を整備しました。

テスト駆動開発による組み込みプログラミングをgoogletestでやる8章
 テスト駆動開発による組み込みプログラミング～モック＆フラッシュドライバ編～
テスト駆動開発による組み込みプログラミングをgoogletestでやる～SOLIDな設計編～

追記

CMakeに対応しました。