大規模なC ++プロジェクトでユニットテストを実装するにはどうすればよいですか？
大規模なマルチプラットフォームアプリケーションの構築の一環として単体テストを使用することを強く信じています。現在、単体テストを別のプロジェクトに含めることを計画しています。これには、コードベースをクリーンに保つという利点があります。しかし、これはテストコードをユニットの実装から分離すると思います。このアプローチについてどう思いますか、cUnitアプリケーション用のJUnitなどのツールはありますか？
C++には多くのテストユニットフレームフォークがあります。 CppUnitは確かに私が選択するものではありません（少なくとも、安定したバージョン1.xでは、多くのテストがなく、多くの冗長なコード行を必要とするため）。これまでのところ、私の推奨フレームワークは CxxTest であり、いつか Fructose を評価する予定です。
いずれにせよ、C++を評価するいくつかの「論文」がありますTU frameworks：
- C++ユニットテストフレームワークジャングルの探索 、Noel Llopis著
- Overload Journal＃78の記事
それは合理的なアプローチです。
nitTest ++ と Boost.Test の両方で非常に良い結果が得られました
私はCppUnitを見てきましたが、私にとっては、C++を対象としたものではなく、JUnitのものの翻訳のように感じました。
更新：最近、私は Catch を使用することを好みます。効果的で使いやすいことがわかりました。
基本コードを共有（動的）ライブラリに分離してから、このライブラリの単体テストの主要部分を記述します。
2年前（2008年）に、Linux Foundationによって展開された大規模なLSBインフラストラクチャプロジェクトに参加しました。このプロジェクトの目的の1つは、Linuxコアライブラリから40.000関数の単体テストを作成することでした。このプロジェクトのコンテキストでは、すべてのテストを自動的に生成するために、 AZOVテクノロジ および API Sanity Autotest という名前の基本ツールを作成しました。このツールを使用して、ベースライブラリのユニットテストを生成してみてください。
UnitTest ++を使用しています。テストは別のプロジェクトにありますが、実際のテストは実際のコードと絡み合っています。テスト中のセクションの下のフォルダーに存在します。つまり：
MyProject\src\<-実際のアプリのソース
MyProject\src\tests <-テストのソース
ネストされたフォルダがある場合（そうでない場合）、それらにも独自の\ testsサブディレクトリがあります。
Cppunitは、C++アプリケーションのJunitに直接相当するものです http://cppunit.sourceforge.net/cppunit-wiki
個人的には、ユニットテストを別のプロジェクトで作成し、すべてのユニットテストと依存するソースコードをビルドする個別のビルド構成を作成しました。場合によっては、クラスのプライベートメンバー関数をテストしたいので、Testクラスをテストするオブジェクトのフレンドクラスにしましたが、プリプロセッサ宣言を通じて「非テスト」構成でビルドするときにフレンド宣言を隠しました。
しかし、テストをレガシーコードに統合していたため、これらのコーディングの体操を行っていました。ユニットテストの目的から始める場合は、より優れた設計が簡単な場合があります。
ライブラリのサブディレクトリにあるソースツリーの各ライブラリの単体テストプロジェクトを作成できます。ライブラリごとにテストドライバーアプリケーションが作成されるため、単一のテストスイートを簡単に実行できます。それらをサブディレクトリに配置することにより、コードベースをクリーンに保つだけでなく、テストをコードの近くに保ちます。
スクリプトは、ソースツリー内のすべてのテストスイートを実行して結果を収集するように簡単に作成できます。
私はオリジナルのCppUnitのカスタマイズされたバージョンを長年使用してきましたが、現在、他の代替手段があります。 GoogleTest は興味深く見えます。
私はあなたがユニットテストとあなたの製品の信頼性を改善するための素晴らしい計画で正しい道を進んでいると思います。
単体テストでは、アプリケーションを別のプラットフォームまたは別のオペレーティングシステムに変換する際のすべての問題が解決されるわけではありません。この理由は、アプリケーションのバグを明らかにするためにプロセスユニットテストが行われるためです。それは単にあなたのシステムに考えられる限り多くの入力を投げ、反対側で結果を待つだけです。これは、サルにキーボードを絶えず叩いてもらい、結果を観察するようなものです（ベータテスター）。
次のステップに進むには、優れた単体テストを使用して、アプリケーションの内部設計に集中する必要があります。私が見つけた最良のアプローチは、「契約プログラミング」または「契約による設計」と呼ばれる設計パターンまたは設計プロセスを使用することでした。コアデザインに信頼性を組み込むのに非常に役立つもう1つの本は、.
開発プロセスのデバッグ：集中力を維持し、出荷日を達成し、しっかりしたチームを構築するための実用的な戦略。
私たちの開発チームでは、プログラマエラー、開発者エラー、設計エラーであると考えられるもの、およびユニットテストとDBCを介してソフトウェアパッケージに信頼性を組み込む方法の両方を非常に綿密に調べ、開発のデバッグに関するアドバイスに従いましたプロセス。