0

ライブラリにテストを追加することにしました。問題は、テスト フレームワークのほとんど (すべて?) が同じアプローチを使用していることです。つまり、テスト対象のコード、テスト、およびフレームワークを含む実行可能ファイルをビルドします。

しかし、重い (内部に大量のコードがある) ライブラリがあり、パブリック関数やクラスが少ない場合はどうすればよいでしょうか? このような状況では、次のようになるまでうまくテストできません。

  1. ライブラリからすべてのシンボルをエクスポートします
  2. すべてのライブラリ ソースを含めて実行可能ファイルをビルドします

広告。1:美味しくない

広告。2: Visual Studio で作業する場合、ライブラリ プロジェクトを「テスト」実行可能プロジェクト (ファイルの追加/削除など) と同期する必要があります。だから私にも似合わない。

他のアプローチはありますか?

4

2 に答える 2

1

2)ができれば、ファイル/フォルダー/プロジェクトを次のように再編成できるはずです。

1) すべての内部関数とオブジェクトを含む静的ライブラリ プロジェクト 2) 任意のフレームワークを使用したテスト プロジェクト (それぞれに賛否両論のあるフレームワークがたくさんあります。初心者の場合は、統合ソリューションまたは単純なフレームワークを選択することをお勧めします)。そのテスト プロジェクトは、静的ライブラリの依存 (ソリューション エクスプローラー メニューで依存関係を追加) する必要があります。したがって、内部実装にテストを追加できます

今は外部APIです。

3) 古い D​​LL プロジェクトは、パブリック API の定義と実装のみを保持します。そして、静的ライブラリの依存。

4) 公開 API のテスト プロジェクトを追加します。

プロジェクトを同期してコードを 2 回コンパイルする必要はありません。努力すれば、内部コードを変更することなく、外部 API 以外のテストも行うことができます。

于 2013-08-15T06:39:51.927 に答える
1

一般に、テスト駆動型プログラミングは、多くの小さな「単位」でうまく機能します。いくつかの肥大化した「ユニット」があると、テスト段階が耐えられなくなります!

私が見る唯一の実行可能な解決策は、コードの特定の部分を分離してから、デバッガーでそれらにステップインすることです。多くの関数があると、通常、前述の問題につながります。単体テストprivate中にそれらに直接アクセスできないため、自明でない場合はデバッガーの使用を検討する必要があります。

于 2013-08-15T06:45:21.227 に答える