1つの実行可能ファイル内のすべてのユニットテスト、またはそれらを分割しますか？

ライブラリなどの1つのソフトウェアのテストを作成する場合、すべてのユニットテストを1つにコンパイルするのが好きですか、それとも複数の実行可能ファイルに分けるのが好きですか？

私が求めている理由は、現在CUnitを使用して、作業中のライブラリをテストしているためです。テストは個別のスイートに分割され、1つの実行可能ファイルにコンパイルされ、障害の印刷出力が完成します。現在、そのライブラリのビルドシステムはCMake（名前にもかかわらず、CUnitとはほとんど関係ありません）であり、独自のテストフレームワークCTestが付属しています。CTestを使用すると、テストとして機能する実行可能ファイルのリストを登録できます。

自動テストの実行にCTestを使用するかどうかを考えています。ただし、これには、これまでに作成したテストを別々のコンパイルターゲットに分割する必要があります。そうしないと、テストの選択的な実行など、CTestsの高度な機能の一部を実際に利用できません。

これは、どのツールを使用するか、それらの処理と規則の問題であることがわかりますが、それとは別に、単一のテスト実行可能ファイルを個別のテスト実行可能ファイルよりも好む他の理由はありますか？またはその逆？

私は自動テストを個々のバイナリで実行するか、少なくとも「グループ」グループごとにまとめて、単純なシェルスクリプトから呼び出します（ゼロ以外の終了コードが失敗を通知し、stderrの出力がキャプチャされる場合があります）説明を記録します）。このようにして、テストの柔軟性を完全に保ちます-コマンドラインから直接個々のテストを実行できます。必要に応じて、あらゆる種類の派手なスクリプトを作成したり、再コンパイルせずに適切に並べ替えたりできます。

しかしさらに重要なことは、異なる言語で書かれたテストや、同じ実行で異なるツールチェーンを使用したテストを含めることができることです。例えば、私が書いた単体テストはプロジェクトのメイン言語である可能性が高く、それらを実行するのはバイナリをビルドして呼び出すことです。しかし、データベースをテストしたいので、SQLスクリプトをデータベースに直接送りたい場合があります。コード上で静的コード分析ツールを実行したい場合があります（それが単なるリンターの場合でも）。妥当性チェッカーを通して静的HTMLを実行したい場合があります。grepコードベースでコマンドを実行して、疑わしい構成要素、コーディングスタイル違反、または「レッドフラグ」キーワードをチェックできます。可能性は無限です-コマンドラインから実行でき、「ゼロ終了ステータスはOKを意味する」に準拠していれば、それを使用できます。

1つのアプリケーションの単体テスト（または一般的に共有されるライブラリのパッケージ）に1つのライブラリを使用する傾向があります。そのライブラリ内で、テストフィクスチャのテスト対象オブジェクトの名前空間を複製または近似しようとします（主にNUnitを使用しています）。.NETでは、各バイナリのビルドに固有のオーバーヘッドがあり、同じLOCを持つ10プロジェクトソリューションのビルド時間よりも20プロジェクトソリューションのビルド時間が長くなるため、これによりコンパイルが簡素化されます。テストバイナリはとにかく配布されないので、テストをバイナリに編成することはあなた自身の便宜のためであり、YAGNIは一般にここでどこでも適用されると思います。

現在、私は通常、tdammersが持っている考慮事項を持っていません。私のコードは事実上すべて1つの言語であり、SQL文字列を含むテストは単体テストではありません（クエリプロデューサーが特定の条件を指定して期待されるSQL文字列を返すことをテストしている場合を除く）。 UI（多くの場合、それは単に不可能です）。また、ビルドボットやIDEプラグインなどのサードパーティツールで受け入れられている単体テストライブラリも使用しているため、個々のテストや部分的なスイートなどの実行に関する懸念は最小限に抑えられています。