15

私はTDDを始めたばかりで、他の人がテストを実行するためにどのようなアプローチを取るのか興味があります。参考までに、私はグーグルのテストフレームワークを使用していますが、この質問は他のほとんどのテストフレームワークとC /C++以外の言語に当てはまると思います。

これまでの私の一般的なアプローチは、次の3つのいずれかを行うことでした。

  1. アプリケーションの大部分を静的ライブラリに書き込んでから、2つの実行可能ファイルを作成します。1つの実行可能ファイルはアプリケーション自体であり、もう1つはすべてのテストを実行するテストランナーです。どちらも静的ライブラリにリンクしています。

  2. テストコードをアプリケーション自体に直接埋め込み、コンパイラフラグを使用してテストコードを有効または無効にします。これはおそらく私がこれまで使用した中で最良のアプローチですが、コードが少し乱雑になります。

  3. テストコードをアプリケーション自体に直接埋め込みます。特定のコマンドラインスイッチを指定すると、アプリケーション自体を実行するか、アプリケーションに埋め込まれたテストを実行します。

これらのソリューションはどれも特にエレガントではありません...

どうしますか？

4

7 に答える 7

6

あなたのアプローチはありません。1は、私が常にC /C++とJavaで行ってきた方法です。ほとんどのアプリケーションコードは静的ライブラリにあり、アプリケーションに必要な余分なコードの量を最小限に抑えるようにしています。

Pythonやその他の動的言語でTDDにアプローチする方法は、アプリケーションとテストのソースコードをそのままにして、テストランナーがテストを見つけて実行するという点で少し異なります。

于 2010-04-21T08:10:00.213 に答える
3

私は2つのアプローチを使用します。dllの場合、単体テストをdllにリンクするだけです。簡単です。実行可能ファイルの場合、実行可能プロジェクトと単体テストプロジェクトの両方でテストされているソースファイルを含めます。これにより、ビルド時間がわずかに長くなりますが、実行可能ファイルを静的ライブラリとメイン関数に分離する必要がないことを意味します。

単体テストにはboost.testを使用し、プロジェクトファイルを生成するためにcmakeを使用していますが、これが最も簡単な方法です。また、大規模なレガシーコードベースに単体テストをゆっくりと導入しているので、他の開発者に不便をかけ、単体テストを思いとどまらせる場合に備えて、最小限の変更を導入しようとしています。ユニットテストのためだけに静的ライブラリを使用することは、それを採用しない言い訳と見なされるかもしれないのではないかと心配しています。

そうは言っても、静的ライブラリのアプローチは、特にゼロから始める場合には良いアプローチだと思います。

于 2010-04-21T09:05:25.337 に答える
3

C / C ++アプリの場合、1つ以上のdllにできるだけ多くのコードを含めるようにしています。メインのアプリケーションは、起動してdllに渡すための最低限のものです。DLLは、テストアプリケーションで使用するために必要な数のエントリポイントをエクスポートできるため、テストがはるかに簡単です。

DLLにリンクする別のテストアプリケーションを使用します。私は、テストコードと「製品」コードを別々のモジュールに保持することに強く賛成です。

于 2010-04-21T09:16:53.160 に答える
3

私はdllよりも静的ライブラリを好む傾向があるので、私のC ++コードのほとんどはとにかく静的ライブラリになります。そしてあなたが知っているように、それらはdllと同じくらい簡単にテストできます。

exeに組み込まれるコードの場合、テスト対象で通常exeに組み込まれているソースファイルを含む別のテストプロジェクトがあるか、ほとんどのexeを含む新しい静的ライブラリを作成してテストします。他のすべての静的ライブラリをテストするのと同じ方法です。私は通常、新しいプロジェクトで「ライブラリ内のほとんどのコード」アプローチを採用し、既存のアプリケーションにテストをレトロフィットする場合は、「exeプロジェクトからテストプロジェクトにソースファイルをプルする」アプローチを採用しています。

私はあなたのオプション2と3がまったく好きではありません。2のビルド構成を管理することは、必要なソースを単純に取り込む別のテストプロジェクトを用意し、3で提案したようにすべてのテストをexeに含めるよりもおそらく難しいです;）

于 2010-04-21T09:22:39.357 に答える
2

私は＃1で行きます、いくつかの理由は

  • 各libが正しくリンクしていることを確認できます
  • 製品に余分なコードは必要ありません
  • 個々の小さなテストプログラムをデバッグする方が簡単です
  • 一部のテスト（通信テストなど）では、複数の実行可能ファイルが必要になる場合があります

C ++のビルドとテストでは、ターゲット実行可能ファイルの選択をテストとして実行し、結果の要約を出力できるCMakeを使用するのが好きです。

于 2010-04-21T09:21:22.603 に答える
0

個人的に、私はあなたに少し依存する別のアプローチを使用します：

テストするプロジェクトはそのままにしておきます。実行可能ファイルの場合は、実行可能ファイルのままにしておく必要があります。すべてのobjファイルを静的ライブラリに集約するために、ビルド後のアクションを作成するだけです。

次に、テストフレームワークと以前に生成された静的ライブラリをリンクして、テストプロジェクトを作成できます。

あなたの質問に対応するいくつかのトピックがあります：

于 2013-11-05T13:32:28.850 に答える
-2

フレームワークでサードパーティのテストランナーを使用しており、ビルドスクリプトにテストを含めています。テストは本番コード（外部dll）の外部にあります。

于 2010-04-21T07:07:19.273 に答える