2
ユニットテストの効率を最大化するには、C ++ユニットテストコードをどのように編成する必要がありますか？
この質問は、単体テストフレームワークに関するものではありません。 この質問は、単体テストの作成に関するものではありません。 この質問は約あるところ書かれたUTのコードを配置する方法と、/とき/コンパイルし、それを実行する場所。 レガシーコードを効果的に使用するにあたって、Michael Feathersは次のように主張しています。 優れた単体テスト...高速で実行 そしてそれ 実行に1/10秒かかる単体テストは、低速の単体テストです。 これらの定義は理にかなっていると思います。私はまた、ユニットテストのセットと、より長い時間がかかるコードテストのセットを別々に保持する必要があることを示唆していると思いますが、それが（非常に）高速に実行される場合、ユニットテストと呼ばれるものだけに支払う代償だと思います。 明らかに問題 ++ Cでは、「実行」へのあなたのユニットテスト（複数可）、あなたがする必要があります。 コードを編集します（使用している「サイクル」に応じて、本番またはユニットテスト） コンパイル リンク 単体テスト実行可能ファイルの開始（s） 編集（奇妙な近い投票の後）：詳細に入る前に、ここでポイントを要約してみます： （テスト）コードの編集とテストコードの実行の両方が効率的になるように、C ++ユニットテストコードを効果的に編成するにはどうすればよいですか？ 最初の問題は、その後、決定することですどこようにユニットテストコードを配置します： 関連する製品コードと組み合わせて編集および表示するのは「自然」です。 現在変更しているユニットのコンパイルサイクルを開始するのは簡単です。 次に、関連する2番目の問題は、フィードバックが瞬時に行われるようにコンパイルするものです。 極端なオプション： 各Unit-Test-Test-Unitは個別のcppファイルに存在し、このcppファイルは（テストするソースコードのユニットファイルと共に）個別にコンパイルおよびリンクされ、単一の実行可能ファイルにリンクされます。 （+）これにより、単一のテストユニットの起動（コンパイル+リンク！）時間を最小限に抑えることができます。 （+）テストは1つのユニットのみをテストするため、超高速で実行されます。 （-）スイート全体を実行するには、膨大な数のプロセスを開始する必要があります。管理することが問題になる場合があります。 （-）プロセス開始のオーバーヘッドが見えるようになる 反対側は、テストごとに1つのcppファイルを持っていますが、すべてのテストcppファイルは（テストするコードとともに）1つの実行可能ファイルにリンクされています（モジュールごと/プロジェクトごと/選択を選択してください）。 （+）変更されたコードのみがコンパイルされるため、コンパイル時間は問題ありません。 （+）実行するexeは1つしかないため、スイート全体の実行は簡単です。 （-）任意のオブジェクトを再コンパイルすると再リンクがトリガーされるため、スイートはリンクするのに時間がかかります。 （-）（？）スーツの実行には時間がかかりますが、すべてのユニットテストが高速であれば、時間は問題ないはずです。 それでは、実際のC ++ 単体テストはどのように処理されますか？夜間/毎時だけ実行する場合、2番目の部分は実際には重要ではありませんが、最初の部分、つまりUTコードを本番コードに「結合」する方法です。フォーカスは常に重要だと思います。（そして、開発者がUTコードに焦点を合わせている場合、彼らはそれを実行したいと思うので、パート2に戻ります。） 現実世界の物語と経験に感謝します！ ノート： この質問は、意図しないプラットフォームとメイク/プロジェクトシステムを意図的に残します。 質問タグ付きUT＆C ++は開始するのに最適な場所ですが、残念ながらあまりにも多くの質問、特に回答が詳細や特定のフレームワークに集中しすぎています。 少し前に、ブーストユニットテストの構造に関する同様の質問に答えました。この構造は、「実際の」高速な単体テストには欠けていることがわかりました。そして、私は他の質問が狭すぎると思うので、この新しい質問です。