あなたの状況で使用する最適な単体テストフレームワークを決定する変数はたくさんあります。選択に影響する可能性のあるアイテムは次のとおりです。
- ターゲット言語。
- 利用可能なライブラリのサポート。たとえば、libcまたはそのカットダウンバージョン。
- ターゲットのオペレーティングシステム。例：なし、FreeRTOS、カスタム。
ほとんどのxUnitタイプのフレームワークは、有用な基本レベルの機能を提供します。私は過去にCunitを使用してある程度の成功を収めています。（Ubuntu / Debianのlibcunit1-devパッケージ）。ほとんどのフレームワークではlibcを使用可能にする必要があり、一部のフレームワークでは追加のOSサポートが必要になります。
わずか3行の長さの別の代替はMinunitです。
マイクロコントローラーをターゲットとして使用した単体テストは、テストのダウンロード、実行、および結果の取得に適した環境を提示できるようにする必要があるため、非常に面倒であることがわかりました。これを可能にするプラットフォームを適切に配置することは、大きなタスクです。
私が取ったもう1つのアプローチは、ホストでユニットテストを行い、ドライバーとアプリケーションコードの間に抽象化レイヤーを実装することです。ターゲットにgccを使用しているため、コードもホストでコンパイルする必要があります。
通常、コンパイルホストでのテストは、ホストOSとそのすべてのツールを完全にサポートしているため、非常に簡単です。たとえば、ホストでテストする場合、ターゲット上で実行される実際のドライバーと同じインターフェイスを備えたモックバージョンのワイヤレスドライバーがあります。ホストバージョンはUDPパケットを使用してワイヤレスパケット転送をシミュレートします。モックドライバーはパケットをドロップする機能をサポートしているため、プロトコルをテストできます。
私が取り組んでいた製品では、スレッドOSが使用されていたため、ホストOSでテストするための抽象化レイヤーは代わりにpthreadを使用していました。
完全ではありませんが、テストを作成して実行するのが簡単であればあるほど、より多くのテストケースを実装する可能性が高くなります。コードを異なるプラットフォームで実行することのもう1つの利点は、コードが移植可能であることをテストすることです。ターゲットとホストのアーキテクチャが異なる場合、エンディアンの間違いをすばやく見つけることができます。
私は少し話題から外れましたが、これらのアイデアがテストフレームワークとテスト方法の選択に役立つかもしれないと感じています。