flowchart TD
A["ユーザーが Ceedling コマンドを実行"] --> B["テストスイートの探索（test/test_*.c）"]
B --> C["必要なモックの自動生成（CMock）"]
C --> D["Unity によるテストランナー生成"]
D --> E["コンパイル & リンク（gcc/clなど）"]
E --> F["テスト実行"]
F --> G["結果の集約 & レポート表示"]
大別すると
C のユニットテスト統合フレームワーク，
テストの構成管理，ビルド管理，テスト実行を一括で自動化．
project.yml によりビルド設定を集中管理．
Unity や CMock と連携し，テストランナーやモックコードを自動生成．
ceedling test:all のようなコマンドでテストプロセス全体を再現性高く実行．
コンパイル，リンク，結果レポートの生成も自動化．
Ceedling は「テストドリブン開発」として利用される．
アサート関数を中心にテストを表現する．
TEST_ASSERT_EQUAL(expected, actual)
TEST_ASSERT_TRUE(condition)
TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
特徴
Unity は「C の JUnit」に相当
Ceedling 環境に統合された モック生成ツール，
外部依存を切り離したユニットテストを実現する．
foo.h）からモック関数を自動生成．EXPECT_CALL_FOO(…) のような形でテストコードから期待を記述．CMock は外部I/Oを持つコードのテストを容易にし，
制御不能な依存を完全にテスト環境側に置き換える仕組みを提供する．
flowchart TD
A["ユーザーが Ceedling コマンドを実行"] --> B["テストスイートの探索（test/test_*.c）"]
B --> C["必要なモックの自動生成（CMock）"]
C --> D["Unity によるテストランナー生成"]
D --> E["コンパイル & リンク（gcc/clなど）"]
E --> F["テスト実行"]
F --> G["結果の集約 & レポート表示"]
sequenceDiagram
participant User as "ユーザー"
participant Ceed as "Ceedling"
participant Unity as "Unity"
participant CMock as "CMock"
participant GCC as "コンパイラ"
User->>Ceed: "ceedling test:add"
Ceed->>Ceed: テストファイル抽出
Ceed->>CMock: 必要なモック生成
CMock-->>Ceed: モックCファイル
Ceed->>Unity: テストランナー生成
Unity-->>Ceed: ランナーコード
Ceed->>GCC: ビルド
GCC-->>Ceed: 実行ファイル
Ceed->>User: テスト結果を表示
仕様と実装の確認では無いテスト
主にパフォーマンス改善やボトルネック分析に使用される． 性能要件の診断に不可欠で，テスト中の挙動把握にも役立つ．
プログラムの実行過程を詳細に記録し，制御フローやシステムコールの履歴を把握する手法． デバッグ，高度な障害解析，セキュリティフォレンジクスに用いられる．
実行時の正確なメモリ動作を追跡し，不正アクセスやリークを検出する． サニタイザより詳細で強力だが，オーバーヘッドは高い．
プログラムを実行しながら状態空間を探索する． 並行プログラムのデッドロックや競合検出に特に強い．
考え方
車載組込み・モダンテスト技法 2025