私は、大規模なマルチプラットフォーム アプリケーションの構築の一環として単体テストを使用することを強く信じています。現在、単体テストを別のプロジェクト内に置くことを計画しています。これには、コード ベースをクリーンに保つという利点があります。ただし、これにより、テストコードがユニットの実装から分離されると思います。このアプローチについてどう思いますか?また、C++ アプリケーション用の JUnit のようなツールはありますか?
46832 次
9 に答える
23
C++ 用の Test Unit フレームフォークが多数あります。CppUnit は確かに私が選ぶものではありません (少なくとも安定したバージョン 1.x では、多くのテストがなく、多くの冗長なコード行が必要になるため)。これまでのところ、私の好みのフレームワークはCxxTestで、いつかフルクトースを評価する予定です。
とにかく、C++ TU フレームワークを評価するいくつかの「論文」があります。
- C++ 単体テスト フレームワーク ジャングルの探索、 Noel Llopis 著
- Overload Journal #78 の記事
于 2008-09-18T11:57:34.100 に答える
12
それは合理的なアプローチです。
UnitTest++とBoost.Testの両方で非常に良い結果が得られました
私は CppUnit を見てきましたが、C++ を対象としたものというよりは、JUnit の翻訳のように感じました。
更新:最近はCatchを使用することを好みます。効果的で使いやすいと思いました。
于 2008-09-18T11:15:50.893 に答える
3
基本コードを共有 (動的) ライブラリに分離してから、このライブラリの単体テストの大部分を記述する必要があります。
2 年前 (2008 年)、私は The Linux Foundation によって展開された大規模な LSB インフラストラクチャ プロジェクトに関与していました。このプロジェクトの目的の 1 つは、Linux コア ライブラリから 40.000 関数の単体テストを作成することでした。このプロジェクトのコンテキストでは、すべてのテストを自動的に生成するために、 AZOV テクノロジとAPI Sanity Autotestという名前の基本ツールを作成しました。このツールを使用して、基本ライブラリ (ies) の単体テストを生成してみてください。
于 2011-01-25T15:50:48.803 に答える
2
UnitTest++を使用しています。テストは別のプロジェクトにありますが、実際のテストは実際のコードと絡み合っています。それらは、テスト中のセクションの下のフォルダーに存在します。つまり、
MyProject \ src\<-実際のアプリのソース
MyProject\src \ tests <-テストのソース
ネストされたフォルダーがある場合（およびネストされていない場合）、それらにも独自の\testsサブディレクトリがあります。
于 2008-09-18T12:08:37.443 に答える
2
単体テストで正しい道を歩んでいると思います。製品の信頼性を向上させるための素晴らしい計画です。
ただし、アプリケーションを別のプラットフォームや別のオペレーティング システムに変換する場合、単体テストですべての問題が解決されるわけではありません。この理由は、アプリケーションのバグを発見するためにユニット テストが実行されるプロセスにあります。想像できる限り多くの入力をシステムに投入し、反対側で結果を待つだけです。猿にキーボードをたたき続けさせて結果を観察するようなものです (ベータ テスター)。
次のステップに進むには、適切な単体テストを使用して、アプリケーションの内部設計に集中する必要があります。私が見つけた最良のアプローチは、「契約プログラミング」または「契約による設計」と呼ばれる設計パターンまたは設計プロセスを使用することでした。コア設計に信頼性を組み込むのに非常に役立つもう 1 つの本は、.
開発プロセスのデバッグ: 集中力を維持し、出荷日を守り、強固なチームを構築するための実践的な戦略。
私たちの開発チームでは、プログラマーのエラー、開発者のエラー、設計のエラーと見なされるものと、DBC を介してソフトウェア パッケージに単体テストと信頼性を組み込む方法の両方を使用し、開発のデバッグに関するアドバイスに従う方法を綿密に調べました。プロセス。
于 2008-09-18T11:41:26.167 に答える
1
Cppunit は、C++ アプリケーションの Junit と直接同等です http://cppunit.sourceforge.net/cppunit-wiki
個人的には、別のプロジェクトで単体テストを作成し、すべての単体テストと依存ソース コードをビルドする別のビルド構成を作成しました。場合によっては、クラスのプライベート メンバー関数をテストしたいので、Test クラスをテスト対象のオブジェクトのフレンド クラスにしましたが、プリプロセッサ宣言を介して「非テスト」構成でビルドするときにフレンド宣言を非表示にしました。
ただし、テストをレガシーコードに統合していたため、これらのコーディング体操を行うことになりました。単体テストの目的から始めている場合、より良い設計は単純かもしれません。
于 2008-09-18T11:19:48.513 に答える
1
ソース ツリー内の各ライブラリの単体テスト プロジェクトを、そのライブラリのサブディレクトリに作成できます。最終的にライブラリごとにテスト ドライバー アプリケーションが作成されるため、単一のテスト スイートを簡単に実行できます。それらをサブディレクトリに配置することで、コード ベースをクリーンに保つだけでなく、テストをコードに近い状態に保ちます。
ソース ツリー内のすべてのテスト スイートを実行し、結果を収集するスクリプトを簡単に作成できます。
私は元の CppUnit のカスタマイズされたバージョンを何年も使用して大成功を収めてきましたが、現在は他の代替手段があります。 GoogleTestは面白そうです。
于 2008-09-18T11:36:55.133 に答える
1
tut http://tut-framework.sourceforge.net/の使用 は非常に簡単で、ヘッダー ファイルのみで、マクロはありません。XML 結果を生成できます
于 2008-09-18T12:48:04.120 に答える