クロスコンパイルも必要な組み込みデバイスのユニットテストフレームワークとしてチェックを使用した人はいますか?
それは良い考えですか、それとも何か他のもの (embunit など) を使用する必要がありますか?
その場合、Makefile.ams と configure.ac はどのように記述すればよいですか? そもそもautotoolsを使用していないため、このクロスコンパイルのすべては確かに役に立ちません...
1 つまたは 2 つの環境でしかコンパイルしないため、実際の構成チェックをすべてスキップすることもできますが、ターゲットへのコンパイル チェックは必要ですか? 実際のフレームワークをテスト コードにリンクする方法が説明からわかりません。
必要な最小限のファイルは何ですか? 例はすべての構成を行いますが、何を省略できるかわかりません。
私が見る限り、「check」は fork() システムコールを使用しています。組み込みターゲットで UNIX ベースのオペレーティング システムを使用していない場合、ここで問題が発生します。第 2.1 章のcheck マニュアル ページには、別の単体テスト フレームワークの優れた概要が記載されています。ほとんどのフレームワークは、一部のオペレーティング システム コールまたは組み込みターゲットに存在しない可能性がある一部の標準ライブラリ関数のいずれかに依存しています。
マクロ式ユニット テスト フレームワーク MAESTRA が組み込みプラットフォームで非常に役立つことがわかりました。数年前、embedded.com に興味深い記事がありました: Doing C code unit testing on a shoestring .
しかし、多くのサードパーティ コードや既存のコード ベースを扱っている場合、MAESTRA は最良の選択ではない可能性があります。これは、コード インストルメンテーションが動作するように特別なコーディング標準を強制するためです。これは、会社独自のコーディング標準と衝突する可能性もあります。