1

ますます大きくなるプロジェクトがあり、このプロジェクトで別の人が私を助けてくれるので、私は私たちの会社で正式なユニットテストを紹介し始めています。だから私は彼がしていることがすべてを壊さないこと、そしてその逆ではないことを確認する必要があります。

CIサーバーも紹介したいのですが、これは他の質問のトピックになります。さて、質問は次のとおりです。私は現在「The Art Of Unit Testing」（これは提案された傑作です！）を読んでおり、著者が強調しているのは、ユニットテストは統合テストとは異なるということです。それは私には明らかであり、私がよく理解していれば、ビジネスロジックの単体テストはデータベース接続などに依存することを避ける必要があります。まず第一に：私は正しいですか？

それで、私が正しいと仮定すると（つまり、BLLを単体テストするときに、データベースをスタブ化する必要があります）、どのように実行しますか？dbモッキング用のフレームワークがあることを読みました。これらのいずれかを使用する必要がありますか？どちらを使いますか？

次の質問：これが正しい方法だと本当に思いますか？つまり、私のプロジェクトでは、BLはEntityFrameworkを介してデータベースとインターフェイスします。したがって、たとえば、私のBLLのメソッド "UpdateItem"が呼び出されると、それは何かを実行してからObjectContextを保存します。このObjectContextは、BLで削除する必要のあるEntityFrameworkの依存関係です。しかし、私はそのような方法で何をテストする必要がありますか？DALを一緒にテストせずにBLレイヤーのユニットテストを本当に理解することはできません...いくつか例を教えてください。

あなたの努力に感謝します！

マルコ

4

2 に答える 2

4

はい、

ビジネス ロジックの単体テストは、データベースに依存しないようにする必要があります

あなたはそれについて正しいです。

次のことをお勧めします。

  • 実際の DB 呼び出しの代わりにスタブを使用して、ビジネス層の一連の単体テストを使用します。DB コンポーネントを抽象化している場合は、最適なもの (偽のクラスまたはモック ライブラリを所有している) で DB をスタブできます。
  • 一連の統合テストを使用して、実際の DB 呼び出しをテストします (それだけです!)

単体テストと統合テストの主な違いは次のとおりです。* 単体テストは高速で、構成は必要ありません * 統合テストは遅く、適切な構成が必要な場合があります (データベースをセットアップし、適切な接続文字列が存在する必要があります)それ）。

コードに変更を加えるたびにビジネス ユニット テストを頻繁に実行できるので、これは良いことだと思います。行った変更によって何も壊れていないという非常に迅速なフィードバック (通常は 1 ～ 2 秒以内) が得られるため、これは重要です。

ときどき、統合テスト (時間がかかります) を実行して、DB がまだ正しく機能することを検証できます。

また、あなたが言及した本を読むことをお勧めします。これは、このトピックに関する非常に重要な情報源であると考えています。

于 2012-01-08T09:49:58.020 に答える
0

データベースをスタブ化することは大きな作業であり、それだけの価値はないと思います。単体テストに適した慎重に準備されたデータを使用して、特別なデータベースコピーを用意することをお勧めします。

テストは、テストの最後にロールバックされるトランザクション内で実行できます。このように、単体テストデータベースはテストによって変更されることはなく、常に既知の状態に保たれます。

私はブログのユニットテストにトランザクションを使用するでそれについて書きました。linq-to-sql用のサンプルコードがありますが、同じアプローチがエンティティフレームワークでも機能します。

于 2012-01-08T09:40:44.253 に答える