6

ソフトウェア開発プロジェクトで、Visual Studio の Microsoft テスト フレームワークを使用して、自動テストを実装したいと考えています。いくつかのテストを作成しましたが、全体として非常に使いやすいです。

ビジネス オブジェクト、より具体的にはデータベースの読み取りと書き込みをテストするためのより良い方法は何ですか。

ユーザー インターフェイスがテストされる開発データベースとは別のテスト データベースをセットアップし、そのデータベースに対してテストするのが最善ですか? 基本的には、ジャンクデータで埋めるだけです。

AddUser メソッドをテストしている場合、ユーザーを追加し、テストを確認してから、ユーザーを削除しますか?

1 つのテスト メソッドで各 CRUD メソッドをテストしますか?

最後に、文字列が正しいサイズであること、開始日が終了日よりも前であること、CustomerId が正しい Customer であることなどの検証など、個々のビジネス ルールについてはどうでしょうか。

私はこれがかなり幅広い質問であることを認識しています... 方向性を探しているだけです... 赤ちゃんの一歩を踏み出しています。

詳しくは...

良い答えがたくさん！モック データベースを作成できるかどうかはわかりません。オブジェクトのフレームワークとして CSLA を使用しています。これをモック オブジェクトでテストできるようにするには、かなりのリファクタリングが必要です。これについて調べてみます。ただし、ある時点で、データベースの相互作用をテストしたいと思います...模擬データベースを使用する場合、データベース通信を実際にどこで/いつテストしますか?

もう 1 つの質問...各テスト メソッドを他のテストに依存しないようにするのが最善ですか?

4

8 に答える 8

8

理想的には、データベースに直接アクセスするのではなく、ヘルパー オブジェクトまたはある種の ORM (オブジェクト リレーショナル マッピング) フレームワークを使用するビジネス オブジェクトが必要です。次に、データベースなしで BO をテストし、場合によってはいくつかのヘルパー オブジェクトをモックできます。実際の DB の複雑さを回避し、実際にはビジネス ロジックのみをテストするため、これがおそらく最もクリーンな方法です。

ビジネス ルールと DB アクセスを 1 つのクラスに結合することを避けられない場合 (おそらく問題のある設計ですが、回避するのが難しい場合もあります)、DB に対してテストする必要があります。

ほとんどの場合、唯一の合理的なオプションは、自動テスト用に別の DB を用意することです。テスト メソッドは、セットアップ時にセットアップ時にすべてを削除してから、すべてのデータをロードし、テストを実行して結果を検証する必要があります。

DB を一度初期化してから、同じデータに対してすべてのテストを実行しようとは考えないでください。1 つのテストが誤ってデータを変更し、他のテストが不可解に失敗します。私はそれをして後悔しました... 各テストは本当に独立している必要があります。

これらすべてを行うには、ある種の DB テスト フレームワークを強くお勧めします。これらは、DB をクリーンアップし、必要なデータをロードし、クエリ結果を期待される結果と比較するのに役立ちます。私は DBUnit (Java 用) を使用していますが、他の言語用には他にもたくさんあります。

于 2009-02-14T04:20:59.177 に答える
5

ビジネス オブジェクトがデータベースを認識しないように実装することをお勧めします。タイプに応じてビジネス オブジェクトを適切に保存/取得できるデータ アクセス レイヤーのメソッドを使用します (つまり、テーブルとそれらが対応するオブジェクトとの間に内部マッピングがあります)。ビジネス オブジェクト自体をテストするときは、データベースについてまったく心配する必要はありません。単純にオブジェクトを作成し、リフレクションを使用してプライベート フィールドを設定し、オブジェクトに対してテストを実行します。

データ アクセス レイヤーとやり取りする必要があるコードをテストする場合は、モックを使用してモック データ レイヤーを作成し、目的のオブジェクトを返すか、保存に適切に応答するよう期待を設定します。データ層をインターフェイスに開発する必要がある場合があります (または、モッキングを直接サポートしていない厳格なフレームワークを使用している場合は、モッキング可能なクラスでラップします)。ほとんどのモッキング フレームワークでは、モック実装を作成できるようにするために、メソッドが仮想である必要があります。インターフェイスを使用すると、実装クラスのメソッドが強制的に仮想化されるため、モックがはるかに簡単になります。

于 2009-02-14T04:17:48.687 に答える
2

CSLA を使用した TDD の詳細については、この質問への回答を参照してください。特にこれ。

また、この質問は興味深いかもしれません。

于 2009-06-06T19:37:07.267 に答える
2

依存性注入を使用します。インターフェイスにデータベース メソッドを実装します。次に、制御データを使用してインターフェイスの新しい実装を作成し、該当するシナリオをテストします。

于 2009-02-14T04:25:28.370 に答える
1

DB アクセス層をテストするには、すべてのテストを同じデータベースで実行しないでください。一部のテストは、他のテストの結果に依存するため、失敗する場合があります。したがって、これはあなたが望むものではありません。実際には、すべてのテストの後、テストを実行する前にデータベースのステータスを元のステータスに戻す必要があります。

私の実践では、テスト データ セットを XML に保持し、すべてのテストの前に、XML を使用して db にデータをセットアップします。したがって、すべてのテストは何らかのデータセットに対して実行されます。

于 2009-02-14T04:38:18.823 に答える
1

通常、BO を作成し、それをフィクスチャのセットアップでデータベースに保存し、さまざまな挿入/更新/選択のテストを行ってから、ティアダウンでデータベースからオブジェクトを削除します。特に多くの制約が関係している場合は、物事がきれいに保たれます。テストで作成したものをすべて削除しないと、テストデータベースがすぐに乱雑になる可能性があります。

于 2009-02-14T03:28:26.450 に答える
0

（Javaを使用していないことは知っていますが、以下の一般的な戦略はJavaにまったく依存していません）

私は多くのEJB3/JPAコードを使用するJavaプロジェクトに取り組んでいます。私は、EJBを「デプロイ」し、Hibernateエンティティマネージャーでインメモリデータベース（HSQL）を使用できる一種のモックコンテナーを作成することにしました。

この「コンテナ」は1秒未満で起動し、JPAを介してデータベースにアクセスするコンポーネントを含むほとんどのビジネスコンポーネントをテストできます。たとえば、サービスが複雑すぎてサポートできない場合は、EasyMock（またはその他のモックライブラリ）を使用して偽のサービスを作成し、「コンテナ」にプラグインします。

これまでのところ大成功を収めていますが、模擬インフラストラクチャを実装するのに数日かかりました。

于 2009-02-24T18:28:33.790 に答える