>>426
TDDで目指すのは小さなフィードバックループを作ること
開発者が安心を得つつコーディングできること
安心というのは、ここでいうと例えば「実機で確認されていないコード・機能をベースに、それに依存したコードをさらに積み上げていくこと＝不安な状態」的な

何をもってTDDでいうテストとなるか、って定義は割とどうでもいい気がする
>>423の環境で何をどうすれば開発者が安心できるか、作業のループを小さくしてフィードバックを得られるか、が大事
「これが動けばこのコードは正しい」っていう一般的なテストがあって
それが自動化できてさらにフレームワークで成否確認までできるなら十分
そうでないなら何か妥協したテストでやるしかない

・実機と検証(解析？)環境がどの程度異なっていて、開発者は検証環境をどの程度信頼できるのか
・どの程度の頻度で実機テストができるのか
とかが重要なのでは？
ここらへんは現場を見てないので多分他人には分からない所。

仮に検証環境があまり信頼できないのであれば、そこだけでどれだけ完璧な開発プロセスをこなしてもムダになる危険性が残るだろうから
実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
そうすると一般的なTDDは実践しづらくなると思う。
けど実機でのテストを自動化できるのであれば多少は導入できるかも？

組み込みとか知らんのでとんちんかんなこと言ってたらすまん