Test Driven Development for Embedded C読書会第4回

Yohei @legoboku

#tdd4ec 始まりました。

Yohei @legoboku

最近の #tdd4ec はmrubyの話から始まるな。MIPSのSoCに移植した話。全部で400KBに収まる。

Yohei @legoboku

#tdd4ec 手間のかかる品質保証を効率化したい

Yohei @legoboku

まずは第7章「Introducing Test Doubles」から。 #tdd4ec

CAD @yukikado

#tdd4ec 始まります。

Yohei @legoboku

7章からはモジュールの依存性の問題に取り組む。別の関数、モジュール、データ。 #tdd4ec

Yohei @legoboku

モジュールの依存関係を崩すポイント：インタフェース、カプセル化、データ隠蔽、グローバルデータへの依存排除。 #tdd4ec

Yohei @legoboku

依存先のモジュール（collaborator）を交換可能な設計にする。 #tdd4ec

CAD @yukikado

依存関係のあるコードに対するTDDの適応。まずは依存関係を崩すところから始める。崩すには、依存関係を、インターフェイスへの依存にする必要がある。 #tdd4ec

Yohei @legoboku

例えば、collaboratorを置換することで、network failureを意図したタイミングで発生させることができる。 #tdd4ec

CAD @yukikado

例えば、ネットワーク接続失敗に対するテスト。失敗のケースが、シーケンス中に4箇所あった場合、意図的に、特定のfailureを起こすことはなかなか難しい。これを、test doubleで置き換え、failureをシミュレートすることでテストを容易にできる。 #tdd4ec

Yohei @legoboku

test doublesで依存先モジュール（Depended on Component）を置換することで、依存関係の連鎖を断ち切ることができる。　#tdd4ec

Yohei @legoboku

依存関係の問題は根深い。依存先を断ち切らないと依存先の依存先までついてきてしまう。この推移的な依存関係をいかに減らすかが大事。 #tdd4ec

Yohei @legoboku

test double は実装を完全に置き換えるようなsimulatorsではない。スタントマンが映画の主役と同じイケメンである必要がないのと同じ。役割が分かっていればいい。 #tdd4ec

Yohei @legoboku

code under testはどれくらいの規模か？切り離せる最小単位。 #tdd4ec

CAD @yukikado

test doubleは、実際のモジュールを完全にシミュレートする必要はない。特定の、特別な動作を、TODを騙せるシンプルな実装で良い #tdd4ec

Yohei @legoboku

どれくらいのテスト項目を考えるか？単体テスト、シナリオレベルのテスト、状態網羅のテスト。それでもバグが出てきたりする。 #tdd4ec

Yohei @legoboku

障害が起きたときに問題の切り分けが難しい。実行時のトレースログとか内部状態を出したり。しかし全部出すとログが大量になって、振る舞いが変わってしまったり。 #tdd4ec

Yohei @legoboku

重要度でログのレベルを分けておき、ログの量を抑制して、重要なところだけ確認できるようにする。結合しての実機テストの効率化も大事な気がするな。　#tdd4ec

Yohei @legoboku

動的解析のツールは遅くて使い物にならない？ #tdd4ec

Yohei @legoboku

静的解析で基本的な問題は解決できる。初期化モレ、境界値、ゼロ割とか。 #tdd4ec

CAD @yukikado

動的解析はやっぱり重い。組み込みでは実用レベルでない。 / 静的解析でも大体の不具合は洗い出される #tdd4ec

Yohei @legoboku

静的解析の重要な警告は全てつぶす。どうしてもつぶせない場合は、問題ないかしっかりとレビューする。 #tdd4ec

CAD @yukikado

静的解析ツール…QA・C, FindBugs, etc #tdd4ec

CAD @yukikado

Rubyは黒魔術が黒魔術と分かるようにかけるのが強み #tdd4ec