hardware-tdd

Hardware TDD

機能が完成したと宣言する前に、テストの段階を整えます。純粋な動作はターゲット外でテストできることが多い一方、電圧、ピンマルチプレクサ、負荷時のタイミング、物理的な組み立てについては、引き続きターゲット上での証拠が必要です。

事前確認

ボードとリビジョンの正確な情報、フレームワーク／ツールチェーン、ハードウェアの不変条件、安全上のインターロック、シミュレーターのモデル、利用可能な計測器、テスト治具、ユーザーが求める証明段階を記録します。

手順

1. 要件を、観測可能な動作と安全上の不変条件に落とし込みます。
2. 時刻、シリアル通信、センサー、アクチュエーターをフェイクに置き換え、純粋な C/C++ ロジックのホストテストを作成します。ハードウェアアダプターは薄く保ちます。
3. Wokwi などのシミュレーターは、そのモデルが実際に表現している周辺機器とタイミングに限って使用し、モデルの制約を記録します。
4. 選択したツールチェーンを使い、対象ボードを正確に指定したコンパイルと静的チェックを実行します。
5. 変更を1つずつ確認するターゲットチェックリストを作成します。電源オフ時の導通確認、制御された電源投入、入力の観測、出力の抑止、リセット／復旧、ログを含めます。
6. 計測値、写真、またはシリアル出力を求める物理ゲートを設けます。ホストテストやコンパイルログからターゲットでの成功を推測してはいけません。
7. 失敗を証拠として記録し、次のテストの範囲を限定します。

テストマトリクス

レイヤー	例	証明できること	証明できないこと
ホスト	デバウンス／状態／パケットパーサー	再現可能なロジック	ピン電圧や配線
シミュレーション	モデル化されたセンサー／LED／UART	モデル化された相互作用	レギュレーター、クローン、EMI、熱の挙動
ビルド	正確な FQBN／環境	ソースと依存関係のコンパイル	アップロードや動作
ターゲット	シリアル、メーター、オシロスコープ、写真	観測されたハードウェアの動作	負荷がない場合の実地での信頼性
システム	統合された負荷／故障ケース	シナリオ下での要件	将来の配備における安全性

合理化を防ぐ

近道	対応
「ユニットテストに合格しました。」	物理テストとシステムテストのすべての段階を未完了のままにします。
「Wokwi はボードと一致しています。」	モデルが省略している項目を列挙し、それらをハードウェア上で確認します。
「スケッチをコンパイルできました。」	アップロードの識別情報とターゲット上での観測結果を別途求めます。
「写真で動作が証明できます。」	ボードの識別情報、計測状況、観測結果を求めます。
「完了にして、テストは後で行います。」	証拠がそろうまで、ループ項目をブロック中または needs-review のままにします。

検証

• すべての要件が、テスト、証明段階、成果物のパスに対応付けられています。
• ホスト／シミュレーション／ビルド／ターゲット／システムの結果は、個別にラベル付けされています。
• 物理環境でのみ行う手順では、embedded-project-loop が定める具体的な Physical gate 形式を使用します。
• 失敗したケースと未検証のケースがレポートに明示されています。

共通の出力要件

共通の Arduino スキル仕様を使用します。前提条件、必要なツールとバージョン、実装手順、証明段階ごとのテスト／証拠、既知の制約、復旧／セキュリティに関する注意事項を明記します。