Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013

Test-Driven Development
for Embedded C
by
James W Grenning
Twitterのアカウントはこちら
@jwgrenning
linkedinのアカウントはこちら
www.linkedin.com/in/jwgrenning
（メッセージに今日の研修で知り合ったことを
書いてください）
1
Agile Japan - Tokyo 2013
www.renaissancesoftware.net
james@renaissancesoftware.net
Copyright © 2008-2013 James W. Grenning
All Rights Reserved. For use by training attendees.
付箋を2枚書いて下さい
あなたの開発時間に
占めるテストとデ
バッグの割合は？
プログラマが考えた通
りにコードが動くこと
を確かめるのは誰の仕
事か？
コーディング %
テスティング %
+ デバッギング %
100%
顧客
2
付箋を2枚書いて下さい
開発の何が
好き？
... が好き
... が苦手
開発で一番苦
手な活動は？
3
TDDには色々な要素がある
4

TDDのいくつかの部分について
見ていこう
実際はもっとたくさんある
5
私が答える質問
• TDDとは何か?
• どのように依存関係のあるコードをテストする
か？
• どのようにTDDを組み込み開発に適用するか？
6
知識
理解
スキル
熟練
• 質問する
• 経験を得る
• スキルを築く
間違いたくなければ質問するな。
決して正しくなりたくなければ質問するな
ガブリエル・ベネフィールド
7
• テストを書く
• ビルドされないことを確認する
• ビルドするが失敗する
• ビルドを通す
• リファクタリングする (汚いコード
を綺麗にする)
• 完了まで繰り返す
T
D
D

開発とテストを連続させ、バグを防ぐ
開発
テスト
9
グループ演習
10
Circular Buffer（循環バッファ）
モジュールを作る
41 59 14 33 7 31
In-Index Out-Index
Out-Index In-Index
23 7 66 12 99 16 90
Out-Index In-Index
42 -6 23 7 66 12 99 16 90
Out-Index In-Index
99
11
ニーズ
• Circular Buffer は整数の配列を持つ
• Circular Buffer の使用と完全性を管理するモ
ジュールを作成する
12

テスト駆動開発を始める前に
• API はどうあるべきか？
– 関数に名前をつける
• 初期データ構造はどうあるべきか？
‒ あなたが使う分野を特定する
• どうテストするか？
– 数行で表現する
• どんなテストケースが必要か？
‒ リストを作る
13
分析しすぎに注意
アイディアが
たくさん湧く
分析しすぎ
Ideas
Time
推測の上に推測を重ねている
考えすぎ
行動に移る
タイミング
14
グループ演習に対する
私の解答
演習が終わるまでこの先の資料を見ないこと
15
インタフェースに対する
アイディアを考える
+ Put
+ Get
+ IsEmpty
+ IsFull
//etc
CircularBuffer
16

どのように実装するか？
（ただし、分析し過ぎに注意）
23 7 66 12 99 16 90 99
in-index
out-index
length
buffer pointer
...
Text
17
テストリストを作る
(分析し過ぎに注意)
Circular Buffer Tests
Initially Empty
Transition to empty
Transition to Full
Transition from Full
Put-Get FIFO
Put to full
Get from empty
Filled but not wrapped around
Wrap around
Circular Buﬀerのテスト
最初は空
空に遷移する
満杯に遷移する
満杯から遷移する
FIFOの入出力
空の時に取得する
満杯だが一周しない
一周する
18
C/C++でのTDDステートマシン
（一度に1つの問題を解決する）
必要になればテストリストに新しいテストを追加する
19
デモ
20

TEST(CircularBuffer, empty_after_creation)
{
CHECK_TRUE(CircularBuffer_IsEmpty(buffer));
}
21
bool CircularBuffer_IsEmpty(CircularBuffer * self)
{
return true;
}
すべてのテストをパスする
最もシンプルな実装
22
{
}
TEST(CircularBuffer, not_empty_after_put)
{
CircularBuffer_Put(buffer, 42);
CHECK_FALSE(CircularBuffer_IsEmpty(buffer));
}
23
{
return self->index == 0;
}
bool CircularBuffer_Put(CircularBuffer * self, int value)
{
self->index++
return true;
}
24

{
}
TEST(CircularBuffer, not_empty_after_put)
{
}
TEST(CircularBuffer, empty_after_removing_the_last_item)
{
CircularBuffer_Get(buffer);
}
25
{
return self->index == self->outputIndex;
}
bool CircularBuffer_Put(CircularBuffer * self, int value)
{
self->index++
return true;
}
int CircularBuffer_Get(CircularBuffer * self)
{
self->outputIndex++
return -1;
}
26
コーディングは危険
だから注意深くやろう
• TDDは一度に一つの問題を解
決する
• 最初にテストにフォーカスし
不完全なコードを実装する
• テストが完了したら、コード
はインテグレーションの準備
が完了している
Photo by Andrew Bossi (Own work) [CC-BY-SA-2.5
(www.creativecommons.org/licenses/by-sa/2.5)], via
Wikimedia Commons
27
動作する複雑なシステ
ムは動作するシンプル
なシステムから常に進
化することが分かった
28

あなたのプログラムにはバ
グが埋め込まれる。そして
それらが見つかった時、あ
なたは驚くだろう。
29
30
持続可能性
Speculate Code Test Debug伝統的な開発
開発者が気づいてい
ない、あるいは計画
していない時間
テスト駆動開発 Spec
ulate
Test and Code Debug
遅く感
じる
検討
検討
31
あとでデバッグ型プログラミング
はジャグリングのようだ
32

ナイフを何本ジャグリ
ングするのが好き？
• TDDは一度に一つの問
題を解決する
Photo by Andrew Bossi (Own work) [CC-BY-SA-2.5
(www.creativecommons.org/licenses/by-sa/2.5)], via
Wikimedia Commons
33
• 注意深いやり方が上手くなれば速く進める
注意深いやり方が
近道だ!
34
組み込みソフトウェア
への適用
35
組み込みの何が特別なのか？
• ハードウェアとの並行開発
• ハードウェア・ボトルネック
• クロスコンパイル
• 制約のあるメモリとIO
• ターゲット上でのデバッグ
• アーキテクチャ
36

ハードウェアが
足りない！
• まだ存在しない
• 他の誰かが使っている
• ハードウェアにハグがある
37
38
39
40

を最小化しよう
Debug
on
Hardware
DoH!
Copyright Fox Broadcasting. Used under fair use.
41
TDDを組み込み開発に適用する
42
TDDを組み込み開発に適用する
参照: http://renaissancesoftware.net/files/articles/ProgressBeforeHardware.pdf
43
35
組み込みでの継続的インテグレーション
3. CISはリポジトリの変更を検出する
と、ローカルコピーを更新して、ビルド
とホストベースのテストを実行する。
2. 開発者が定期的
に成果物をチェッ
クインする。
1. 開発者が全てのユ
ニットテストを通
し、成果物をチェッ
クインする。
4.ホスト上のビルド
とテストが成功する
と、CISはビルドし
たバイナリをTMS
に渡す。TMSはそ
れをシミュレータ、
評価ボード/リファ
レンスボード、ター
ゲットシステムなど
にデプロイする。
SCR, CIS と TMS は必ずしも別のマシン
である必要はない
Developer
Workstation
Source Code
Repository
Continuous Integration
Server
Target System
Eval/Reference
System
Simulator
Test Management
System
44

適切なステージで問題を見つける
ステージステージで見つかりそうな問題
1 ロジック、設計、モジュール性、インタフェース、境界条件
2 コンパイラの互換性（言語の機能）
ライブラリの互換性（ヘッダーファイル、宣言）
3 プロセッサ実行の問題（コンパイラとライブラリのバグ）
移植の問題（ワードサイズ、アライメント、エンディアン）
4 ステージ 3 と同じ
ハードウェアインテグレーション問題
ハードウェア仕様の誤解
5 ステージ 4 と同じ
機能仕様の誤解
45
どのように依存関係のある
コードをテストするか？
46
コラボレータのあるモジュール
• LightSchedulerは
RTOSによって1分
毎に起こされる
• ライトの1つがコ
ントロールされる
時間になれば、
LightControllerは
そのライトをオン/
オフするよう指示
される
Time Service
+ GetTime()
+ SetPeriodicAlarm()
Light
Scheduler
+ScheduleTurnOn()
+RemoveSchedule()
+WakeUp()
Light Controller
+ On(id)
+ Off(id)
Hardware RTOS
<<anonymous callback>>
Admin
Console
47
インターフェイスに対してプログラムする
• インターフェイスと
実装を別々の構成
要素に分離する
• この設計はうまく
責務を分離している
<<interface>>
Time Service
+ GetTime()
Light
Scheduler
+ ScheduleTurnOn()
+ RemoveSchedule()
+WakeUp()
<<interface>>
Light Controller
+ On(id)
+ Off(id)
Model 42 Hardware RTOS
Model 42
Light Controller
RTOS
Time Service
<<implements>> <<implements>>
Admin
Console
48

コラボレータのあるモジュールを
テストする
• 可能ならば本物
のコラボレータ
を使う
• フェイクは必要
なときだけ使う
<<interface>>
Time Service
+ GetTime()
Light
Scheduler
Test
Light
Scheduler
+ ScheduleTurnOn()
+ RemoveSchedule()
+wakeUp()
<<interface>>
Light Controller
+ On(id)
+ Off(id)
Light Controller
Spy
Fake
Time Service
49
スケジューラをテストする
TEST(LightScheduler, ScheduleOnTodayNotTimeYet)
{
LightScheduler_ScheduleTurnOn(3, EVERYDAY, 1000);
FakeTimeSource_SetMinute(999);
LightScheduler_Wakeup();
LONGS_EQUAL(LIGHT_NA, LightControllerSpy_GetState(3));
}
TEST(LightScheduler, ScheduleOnTodayItsTime)
{
LightScheduler_ScheduleTurnOn(3, EVERYDAY, 1000);
FakeTimeSource_SetMinute(1000);
LightScheduler_Wakeup();
LONGS_EQUAL(LIGHT_ON, LightControllerSpy_GetState(3));
}
50
部分的なスケルトンで早く設計や
テストのアイデアを試す
51
テストダブル
52

テストダブル
• テストダブルはテストの間、プロダクトコードの
ある部分の代わりになる
• テストダブルはモジュールをユニットテスト可能
にするテストフィクスチャの一部
53
タコのようなテスト依存関係
Test
Code
Under Test
Depended
On
Component
DOC DOC
Transitively
DOC
TDOC TDOCTDOCTDOC
54
タコを管理する
Test
Code
Under Test
Test Double Test Double Test Double
55
可能ならばプロダクションコードを使う
必要な時だけテストダブルを使う
Test
Code
Under Test
Depended
On
Component
Test Double Test Double
Transitively
DOC
TDOC
56

テストダブルの種類
[XUNIT]
• 他の名前
‒ フェイク
‒ モックオブジェクト
‒ スパイ
‒ ヌルオブジェクト
‒ フェイク爆弾
‒ 他にもある
57
Cによるテストダブルの選択肢
• リンク時置換
‒ オブジェクトファイルやライブラリを置換する
• 実行時置換
‒ 関数ポインタ
‒ 関数ポインタテーブル
• プリプロセッサ置換
‒ 私は好きではないが、時々必要になる
• 動く一番シンプルな選択肢を使う
58
C++によるテストダブルの選択肢
• リンク時置換
‒ オブジェクトファイルやライブラリを置換する
• 実行時置換
‒ 1つのクラスを別のものに置き換える
‒仮想関数
‒インタフェースクラス
‒ 1つの関数を別のものに置き換える
‒C関数ポインタ
• プリプロセッサ置換
‒ 私は好きではないが時々必要になる
59
ターゲットへの依存関係を
管理する
60

Spaghetti Slide
Fair use for education: Thanks http://catalinpetrescu.webs.com/apps/photos/photo?photoid=5490225561
関心を分離する
• ハードウェアやOS
の詳細から製品ロ
ジックを分離する
• もしできないならオ
フターゲットでテス
トできない
• あなたのコードの寿
命が短くなる
<<interface>>
Time Service
+ GetTime()
Light
Scheduler
+ ScheduleTurnOn()
+ RemoveSchedule()
+WakeUp()
<<interface>>
Light Controller
+ On(id)
+ Off(id)
Model 42 Hardware RTOS
Model 42
Light Controller
RTOS
Time Service
Admin
Console
62
問題例
• コンパイラベンダーが C を拡張する
• 開発者が ‘asm’ を埋め込む
• ヘッダファイルがベンダーロックインになる
63
コンパイラベンダーが
C を拡張する
//snip...
/* Address Mode Register */
extern cregister volatile unsigned int AMR;
//snip...
//snip...
interrupt void one_ms_tic(void)
{
...
}
//snip...
64

プリプロセッサでベンダー拡張を隠
すため強制的にインクルードする
//hide_stuff.h
#define interrupt
#define cregister
無効化するために hidestuff.h を強制的にインク
ルードする
参照: http://www.renaissancesoftware.net/blog/archives/249
65
開発者が ‘asm’ を埋め込む
void foo(void)
{
do
{
asm("NOP");
asm("PLOP");
asm("READ 0");
status = IORead(0);
} while ((status & ReadyBit) == 0);
}
66
プリプロセッサテストダブル
//nullasm.h
#define asm
asm を無効化するために nullasm.h を強制的に
インクルードする
67
AsmSpy テストダブル
#define asm AsmSpy
void AsmSpy_Create(int size);
void AsmSpy_Destroy(void);
void AsmSpy(const char *);
const char * AsmSpy_Debrief(void);
AsmSpy.h を強制的にインクルードすること
で、すべての asm() 指令は AsmSpy() 呼び出
しに置き換えられ、補足可能になる。
68

asmのモニタ方法を示す
AsmSpyのテスト
TEST(AsmSpy, CaptureAsmInstructions)
{
AsmSpy("NOP");
AsmSpy("FLOP");
AsmSpy("POP");
STRCMP_EQUAL("NOP;FLOP;POP;", AsmSpy_Debrief());
}
asmへの指示を補足するため、AsmSpy.hを強制
的にインクルードする
69
ベンダーのコンパイラに
ロックインするヘッダファイル
#if defined(_ACME_X42)
typedef unsigned int Uint_32;
typedef unsigned short Uint_16;
typedef unsigned char Uint_8;
typedef int Int_32;
typedef short Int_16;
typedef char Int_8;
#elif defined(_ACME_A12)
typedef unsigned long Uint_32;
typedef unsigned int Uint_16;
typedef unsigned char Uint_8;
typedef long Int_32;
typedef int Int_16;
typedef char Int_8;
#else
#error <acmetypes.h> is not supported for this environment
#endif
70
#includeテストダブルを
作成する
#include <stdint.h>
typedef uint32_t Uint_32;
typedef int32_t Int_32;
#endif /* ACMETYPES_H_ */
ベンダー固有インクルードへの依存を制限する
71
質問があればTwitterでどうぞ
http://twitter.com/jwgrenning
私の本の翻訳はこちら
http://www.oreilly.co.jp/books/
9784873116143/
linkedinアカウントはこちら
http://www.linkedin.com/in/jwgrenning
（メッセージに今日の研修で知り合った
ことを書いてください）
http://www.renaissancesoftware.net
http:// www.jamesgrenning.com
質問
72

Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013

Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013

Similar to Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013(20)

More from Yohei Onishi

More from Yohei Onishi(9)

Test-Driven Development for [Embedded] C by James Grenning at Agile Japan 2013