16

CQRS を実装するためのアドバイスの一部が、データベース (またはおそらく LINQ ベースの ORM) に対して直接 ADO.NET クエリを実行するなど、かなり金属に近いクエリの実装を提唱していることを考えると、試して単体テストを行うのは間違いですか?彼ら？

本当に必要なのだろうか？

この問題に関する私の考え：

  1. モック可能な「Thin Read Layer」を提供するための追加のアーキテクチャの複雑さは、アーキテクチャの儀式を最小限に抑えるというアドバイスの性質とは正反対のようです。
  2. ユーザーが作成する可能性のあるクエリのあらゆる角度を効果的にカバーするための単体テストの数は恐ろしいものです。

具体的には、ASP.NET MVC アプリケーションで CQRS を試していますが、コントローラー アクション メソッドの単体テストを行うか、代わりにドメイン モデルをテストするかを考えています。

よろしくお願いします。

4

5 に答える 5

6

私の経験では、適切な非正規化された読み取りモデルを作成している場合に実行する読み取りの 90% ～ 99% は、単体テストを行うことを保証し ません。

CQRS アプリケーションを TDD する最も効果的かつ効率的な方法は、ドメインにコマンドをプッシュする統合テストを作成し、クエリを使用してアサーション用に DB からデータを取得することです。

于 2011-03-03T22:30:50.747 に答える
5

この種のコードの単体テストはあまり有益ではないという意見に同意する傾向があります。しかし、いくつかの有用なテストの余地はまだあります。

ユーザーの読み取りクエリ パラメータの検証を実行する必要があります。その場合は、無効な要求パラメータが適切な例外をスローし、有効なパラメータが許可されることをテストします。

ORM を使用している場合、マッピング コードをテストするには費用対効果の比率が高すぎると思います。ORM が既にテストされていると仮定すると、マッピングにエラーがある可能性がありますが、すぐに見つけて修正できます。

また、データベースに接続できること、および ORM 構成がマッピング例外をスローしないことを確認するために、(同じテスト フレームワークを使用して) いくつかの統合テストを作成することも役に立ちます。実際のデータベースを照会する単体テストを作成したくないのは確かです。

于 2011-02-25T10:57:06.253 に答える
2

おそらくすでにご存知のように、単体テストは、優れた設計よりもコード カバレッジやバグの防止に関するものではありません。急いでいるときは、読み取りモデル イベント ハンドラーのテストをスキップすることがよくありますが、コードを TDD する必要があるすべての理由から、テストを実行する必要があることは間違いありません。

また、HTTP アクションの単体テストも行っていません (.NET MVC ではなく Nancy を使用しているため、コントローラー自体はありません)。

これらは統合ポイントであり、そのほとんどがコマンド ハンドラーとドメイン モデルにカプセル化されているため、多くのロジックを含む傾向はありません。

これらをテストしないのがかなり簡単だと思う理由は、それらが非常に単純で非常に反復的であるためです。私の HTTP ハンドラーについても同じことが言えます。これは、クライアントに応答を返すためのいくつかの基本的なロジックを使用して、要求を処理し、ドメインにコマンドを発行するだけです。

開発中、このコードで間違いを犯すことがよくあります。TDD を使用していれば、おそらくこれらの間違いははるかに少なくなるでしょうが、はるかに時間がかかり、これらの間違いを見つけて修正するのは非常に簡単になる傾向があります。

ここでも TDD を適用する必要がありますが、まだすべて非常に疎結合であり、テストを作成するのは難しくありません。コントローラーのコードの臭いを示す可能性のあるテストを書くのが難しい場合。

于 2011-02-27T21:05:20.003 に答える
1

この単体テストのようなものを私が見た方法は、単体テストでデータベース内に一連のものを作成し、単体テストを実行してから、作成されたものを一掃することです。

過去のある仕事で、オブジェクトとそれらの関係を記述するデータ構造を使用して、このセットアップが非常にうまくいくのを見ました。これは ORM を介して実行され、それらの関係を使用してオブジェクトが作成され、そのデータがクエリに使用され、ORM を使用してオブジェクトが削除されました。単体テストを簡単に設定できるようにするため、すべてのクラスで指定された既定値を、それらの値をオーバーライドしなかった単体テストで使用するように設定します。次に、単体テストのデータ構造は、デフォルト以外の値を指定するだけで済み、単体テストのセットアップがはるかにコンパクトになりました。

これらの単体テストは非常に役に立ち、データベースとのやり取りで多くのバグを発見しました。

于 2011-02-02T01:19:17.343 に答える
0

私のasp.net mvcアプリケーションの1つで、sqrcも適用しました。ただし、SQL と「ADO.NET クエリ」または「Linq」の代わりに、ドキュメント データベース (mongodb)と各コマンドまたはイベント ハンドラーを使用してデータベースを直接更新します。

そして、1 つのコマンド/イベント ハンドラーに対して 1 つのテストを作成しました。そして、100% 単体テストを行った後、私のドメインは 95% 正しく動作することがわかりました。しかし、アクション/コントローラー/UIについては、UIテストを適用しました(セレンを使用)。

したがって、ドメインの単体テスト（コマンド/イベントハンドラーとデータベースへの直接更新）とUIテストの両方が「統合テスト」のようです。

すべてのロジックがコマンド/イベント ハンドラーにカプセル化されているため、少なくともドメイン部分をテストする必要があると思います。

参考までに: 私はまた、ストアド プロシージャを介してデータベースに直接更新するよりも、エンティティ フレームワークから最初にドメイン部分の開発を開始しましたが、ドキュメント データベースには本当に満足していました。いくつかの異なるドキュメント データベースを試しましたが、mongodb が最適のようです。

于 2011-02-02T23:14:31.960 に答える