5

Visual Studio 2005 C++ プロジェクトがあります。これはコンソール アプリケーションです。

テスト ハーネスの下でコードの一部を取得したいのですが、最適な処理方法がわからない問題に遭遇しました。

テスト コードのほとんどが本番環境で通常の .exe になることを望まないので、テスト用に別のプロジェクトを作成するのが最善だと考えました。最初の問題です。この新しいプロジェクトは、残りのコードをどのように呼び出すのでしょうか? レガシ コードを単一のエントリ ポイントを持つ .lib または .dll にして、レガシ コードのメインを呼び出す別のプロジェクトを作成する必要がありますか?

#ifdef TESTINGコードが本番環境の .exe に含まれないように、すべてのテストを完全にファイルに入れるという醜いハックを行う必要がありますか? その場合、テスト フレームワークを条件付きでロードするにはどうすればよいですか? テスト用に別のプロパティ構成を使用しますか?

私は基本的に、Visual C++ のレガシー .exe プロジェクトでテスト ハーネスを取得する方法についての提案を探しています。

4

2 に答える 2

5

まず、Michael Feather の著書「Working Effectsly with Legacy Code」を強くお勧めします。テストのないレガシ アプリに自動化された単体テストを追加する方法がすべてです。「この大量のコードのテストを開始するにはどうすればよいか」と考えている場合は、この本が最適です。

Michael は、C++ コード用のオープン ソースの NUnit に似たテスト フレームワークである CppUnit の作成者でもあります。ここで見つけることができます: http://sourceforge.net/projects/cppunit/。

テストを追加する手っ取り早い方法の 1 つは、ソリューションに UnitTest 構成を追加することです。この構成はコードをコンパイルしますが、それを main.CPP にリンクする代わりに、ビルドから main.cpp を除外し、単体テストを実行するための呼び出しを配置する UnitTestMain.cpp を含めます。私たちはずっと前に、よくわからなかったときにこの方法を始めました。ただし、さまざまな testMyCode.cpp モジュールをすべてさまざまな構成に含めたり除外したりするのに多くの時間を費やすことになり、しばらくすると疲れてきます。開発者はこのアプローチをあまり好まないことがわかりました。

はるかに優れたアプローチは、実際のプロジェクトに依存するビルドを使用して、単体テスト プロジェクトをソリューションに追加することです。プロジェクトの名前が Foo.vcproj の場合は、Foo_test.vcproj と呼びます。このプロジェクトにはテスト コードのみが含まれ、Foo ヘッダーが #include され、コンパイルされた fooCode.obj モジュールにリンクされます。Foo_test ビルドのビルド後のステップとして Foo_test.exe を実行する呼び出しを追加すると、ビルド中に単体テストが自動的に実行されます。いずれかの単体テストが失敗すると、ビルドは失敗します。ビルド サーバーで gated-check-ins が構成されている場合、既存のテストを破壊する変更を誰もチェックインできません。

于 2009-07-21T01:26:31.497 に答える
0

テストするコードのほとんどをライブラリに置くのが最善だと思いますが、すべての場合に必ずしも実用的であるとは限りません。

1 つの解決策は、個別のプロジェクト構成 (例: デバッグ、リリース、およびテスト) を用意し、デバッグおよびリリース構成の下で「ビルドから除外」としてマークされた個別のファイルにテスト コードを含めることです。内でテストを開始する単純なコードを使用するか#ifdef、非テスト ビルドに含まれるテスト ランナーのスタブ バージョンを使用することができます。

別のオプション (かなりハックっぽいですが) からテスト コードを実行しWinMain、通常の old から実稼働コードを実行することもできますmain。「Windows」サブシステムを使用してビルドするとテストが実行され、Consoleサブシステム用にビルドすると本番コードが実行されます。ただし、リンカが呼び出されていないテスト関数を製品ビルドから削除するかどうかはわかりません。

于 2009-07-21T01:18:12.633 に答える