1

直接の質問: 1 つのアプリケーションをテストするには、ワークスペースに 2 つのプロジェクトが必要ですか? 1 つはアプリケーション用で、もう 1 つは単体テスト用です。それとも、1 つのプロジェクトだけをまとめて持つことはできますか?

質問の説明:現在、MinGW を使用して Eclipse C++ で小さなアプリケーションをプログラミングしており、ブースト テスト ライブラリと C/C++ ユニットでテストしたいと考えています。マニュアルとチュートリアルを読みましたが、Boost がメイン関数を作成すると書かれています。これは、2 つの異なるプロジェクト (1 つはアプリ用、もう 1 つはテスト用) が必要であることを意味します。しかし、この場合、コードに変更を加えると、2 回 (両方のプロジェクトで) 変更を行う必要があります。非常に面倒に見えるので、おそらく私が間違っていると思います。おそらく、独自のプロジェクトまたは単体テスト プロジェクトの特定の構成を使用して、単体テストでアプリケーションのソース コードを直接使用する方法があります。

誰にもアイデアがありますか？

どうもありがとう！

4

2 に答える 2

1

あなたが説明したことは、実際に起こるのを待っている災害である問題です。単体テストは、アプリケーションのコードのコピーではなく、アプリケーションのコードをテストする必要があります。しかし、それらをまとめて 1 つのプロジェクトにするべきではありません。

テストをメイン コードに含めることで得られる悪い点について考えてみてください。名前の競合が発生したり、ユニット テストが誤って本番環境の実行可能ファイルにリンクされて出荷されたりする可能性があります。また、テストの正当性を完全に無効にするいくつかのプラクティスを実行する可能性もあり #ifdef UNIT_TESTますif (testing == true) {...}。単体テストが、実際にコンパイルされてすぐに出荷できる本番コードをテストしていない場合、コードが本番環境に対応していることを証明するのに役立ちません。

代わりに、コードを理解しやすく、テストしやすく、構築しやすく、維持しやすいようなプロジェクト編成を強く望む必要があります。そのためには、コード、単体テスト、および運用ラッパーを分離する個別のプロジェクトを必要とする必要があります。

Doctorlove のアドバイスに従って、プログラムのすべてのロジックを含む大規模なライブラリ プロジェクトを実装し、main()実際のロジックが存在する静的ライブラリのみを呼び出す非常に薄い関数を含む別のプロジェクトを作成することを強くお勧めします。次に、すべての単体テストを含む 3 番目のプロジェクトを作成します。main()テスト プロジェクトは、ライブラリにリンクする必要があります。また、テストを実行するには、独自のプロジェクトも含める必要があります。

この構造では、ソリューションの 1 つのビルドでいくつかのことを行う必要があります。最初にライブラリをコンパイルし、次に単体テストをコンパイルしてリンクし、次に単体テストを実行し、それらがすべて合格した場合にのみ、本番プロジェクトをコンパイルしてライブラリにリンクします。このような組織構造により、コードのテストが非常に簡単になり (すべてのビルドでそれ自体がテストされます!)、ビルドが非常に効率的になります (ロジックとテストを 1 回ビルドするだけです)。 . コードの場所。

于 2013-10-16T18:29:40.737 に答える