![組み込みTDDサイクル
●
ステージ1 [TDDのマイクロサイクル]
●
前回までやってきたLEDドライバのテスト駆動開
発のようなものの繰り返し
●
サイクルの中で最も頻繁に行う
●
プラットフォームに依存しないコードを書く
テストコードを書く
→コードを書く
→テストの成功させる
→リファクタリング](https://image.slidesharecdn.com/tdd5-131109231903-phpapp02/85/TDD-for-Embedded-C-5-14-320.jpg)
![組み込みTDDサイクル
●
ステージ2 [コンパイラの互換性チェック]
●
●
●
●
テストしてきたコードを実際のターゲット向けに
コンパイルする
言語機能，ヘッダ，ライブラリにおけるバグに対応
新しくしようする言語機能，ライブラリ，ヘッダの
使用時にやっておくとよい
ターゲット向けコンパイルが通るかチェック
→実際にターゲットで動くかはわからない
●
ビルドに時間がかかるが，ターゲットにダウンロードす
る時間はかからない](https://image.slidesharecdn.com/tdd5-131109231903-phpapp02/85/TDD-for-Embedded-C-5-15-320.jpg)
![組み込みTDDサイクル
●
ステージ3 [評価ボード上でのユニットテスト]
●
●
●
●
ホストシステムでのコードの実行結果と
ターゲット上での結果をチェックする
ターゲットシステム上でも，ホストシステムで予期し
た振る舞いをするか？
ターゲットハードウェアが使えるのであればそちらを
使ってもよい[ステージ4]，がそのハードが本当に信頼
できるかが問題
先に評価ボードで動いていれば，ターゲットで振る舞
いが変わった時にハードのバグだとすぐわかる](https://image.slidesharecdn.com/tdd5-131109231903-phpapp02/85/TDD-for-Embedded-C-5-16-320.jpg)
![組み込みTDDサイクル
●
ステージ4 [ターゲットハード上でのユニットテスト]
●
●
●
目的はステージ3と同じ
ステージ3とは違い，実際のターゲットハードウェアを使っ
てユニットテストを行う．
ターゲットハードウェア固有のテストもできる
→評価ボードは汎用性を高めてあるので
できないテストもある
●
ターゲット上のメモリの容量によってすべてのテストができ
ないかもしれない
→複数のテストスイート（関連するテストケースのセット）
に分割して行う](https://image.slidesharecdn.com/tdd5-131109231903-phpapp02/85/TDD-for-Embedded-C-5-17-320.jpg)
![組み込みTDDサイクル
●
ステージ5 [ターゲット上での受け入れテスト]
●
ターゲット上で自動，及び手動の受け入れテストをする
●
製品機能がきちんと動いているか確認
●
●
自動ではうまくいかないハードウェアに依存するテストは手動でテス
トする
受け入れテスト
●
●
開発したシステムが，要求機能や性能を備えているかどうかを確認す
るテスト
なんで受け入れ？
[クライアント|ユーザ|カスタマー]の指定した要求に答えてるか，その
製品を受け入れることができるかのチェックだから](https://image.slidesharecdn.com/tdd5-131109231903-phpapp02/85/TDD-for-Embedded-C-5-18-320.jpg)
TDD for Embedded C -5章-
- 21. 5.5 デュアルターゲットの非互換性 ● strstrの例 ● ● ● 引数1の文字列の中から引数2の文字列を検索する 空の文字列は，どんな文字列にも含まれるべき if (strlen(other) == 0) もし検索する文字列が空(長さが0)なら return TRUE; それは含まれる else if (strlen(s) == 0) もし検索される文字列が空で，検索する文字列が return FALSE; 空でないならそれは含まれない（空の文字列に空 else の文字列以外は含まれない） return strstr(s, other) !=NULL; それ以外はこのライブラリの strstrで対処できる