2012-01-25 4 views
12

私はTDDを学習していますが、現在は動作しているメソッドがありますが、TDDを使用して再構築していると思います。Writing Unitデータベースを照会するメソッドのテスト

方法は、基本的に、6つのパラメータを受け取り、データベースを照会し、いくつかのロジックを行い、空/ゼロ定義された文字列とint型メソッドのパラメータの値をチェックするが、今、私はよく分からないなど、List<T>

私の最初のテストを返します。する。 TDDを使用していない場合は、DB接続文字列を検索してDB接続を開き、値を読み取るなどのコードを作成するだけです。

もちろん、ユニットテストではできません私はどのように進むべきかアドバイスをしていた。

+5

Nitpick - データベースに照会すると、ユニットテストではなく統合テストになります。 – Oded

+2

@Oded:それは意見と論争の問題です。 –

+1

@Oded - Iveは文章を何度も書いているので、それは現実的ではありません! – Jamiec

答えて

9

TDDは、テストよりも優れた設計に近い点に注意してください。このメソッドはあまりにも多くのことが起こっています。それは「分離の懸念」原則に違反します。

はすでにテストする必要がありますいくつかの領域を特定しました:この方法は、本質的に、6つのパラメータを受け取り、データベースを照会し、いくつかのロジックをして、あなたが持っているList<T>

を返し

そこにはいくつかの別々のステップがあり、コードにはおそらくいくつか隠れているでしょう。それを打ち破ることは、TDDに関してはゲームの名前です。

まず、ロジックを実行する部分を除外することをお勧めします。

メソッドを動的に作成していますか?その部分も分解して、クエリが正しく書かれていることを確認してください。

クエリの実行をスタンドアロンのリポジトリまたは同様のものに置き、それに対して統合テストを書くことができます。そうすれば、現在の複雑なメソッドではなく、データベースにヒットする単純なテストしかできません。

これをそのままテストしようとすると、多くのセットアップを必要とし、すべてのビジネスロジックを複製するモンスターテストが終了する可能性が高くなります。また、壊れたときには、違う。

+0

データベースコールのシミュレーションをシミュレートしたメモリ内のリストを返すモックリポジトリを用意する必要がありますか? – Jon

+0

正確です。あなたのロジックはそれに作用することができます。これにより、処理中のソート/フィルタリング/処理をテストする際に、データベースに頼ることがなくなります。また、将来、DBに不良データが入るのを防ぐため、テストが失敗することもありません。" –

+0

DB/MockDBから情報を返す新しいメソッドに基づいてテストを書くか、または既存のメソッドに基づいてテストを作成して、DB情報を返す新しいメソッドを呼び出すことから何かが返されることを確認しますか? – Jon

6

一般に、TDDを使用してデータベースコードをテストすることについては何も「間違っている」ことはありません。しかし、データベースコードを抽象化してから、それを嘲笑してみるかもしれません。

+0

クエリからデータの一部を返すためにそれを嘲笑? – Jon

+0

はい、かなり。特定のテストのための特定のデータを返す。 –

1

データアクセスレイヤーで単体テストを実行する場合は、DbUnitを参照してください。これは、テスト実行中にデータベースを既知の状態にして、テストデータベースの破損を防止します。

+0

任意の.NET対応ですか?この質問は.NET固有のものです。 –

+0

@DannyVarod素早いGoogle検索でこのプロジェクトが公開されました:http://dbunit-net.sourceforge.net/ –

+0

DALの技術に特化しています。デモ用のDBファイルをソース管理に残しておくと、コピーと添付がより柔軟になります。 –

1

次のことが可能です。

  1. は、データの既知のセットに空白DBや小さなDBのコピーを高めるために、クラス/テストのinitを使用してください。次いで、試験方法において
  2. (DBが空の場合)、テストデータを入力し、クエリを実行し、次に結果を期待して比較結果。テスト/クラスクリーンアップで
  3. はDBを除去します。

これは、あなたのユニットをテストしますが、いくつかのことで、「統合テスト」と考えています。 - 「ユニットテスト」という用語には、「ユニット」という用語のあいまいさに起因する不一致があります。

インメモリDBまたはインプロセスDBを使用して、テスト環境を簡単にすることもできます。

4

方法は、本質的に、6つのパラメータをとるデータベースを照会、 いくつかのロジックを行い、ユニットテスト可能なコードであることがあまりにはるかにあると思われるリスト

を返します!

ユニットテスト可能コードは、非常に具体的なことを行い、小さなモジュールで行うべきです。だから、あなたのケースでは、あなたは(少なくとも)以下にあなたの方法をリファクタリングして分割する必要があります。

  • データベースのクエリ:バッキング・インターフェースでデータプロバイダ内にラップ。そして、あなたの単体テストはこのインタフェースを模擬します。
  • いくつかのロジックがあります:これは単体テストに最適な候補です。これは、データプロバイダインターフェイスを取るだけのモジュールであり、ロジックを実行し、ユニットテストで検証する修正リストを返します。

はまた、ユニットテストは、各テスト可能なモジュールのための少なくとも3つのシナリオをカバーすべき覚え:

  • 陽性試験
  • 陰性試験無効な値の意味のある例外をスロー
  • 試験。

希望すると便利です。

2

もう1つの方法は、テストの前にトランザクションを開始し、その後にロールバックすることです。このようにしてテストは独立しているので、いくつかの定義によれば、単体テストと見なすことができます。

他の回答に記載されているのとは反対に、の後に、より良いデザインになるようにコードをリファクタリングしてにする必要があります。次に、リファクタリングがテストを再実行するだけで何かを壊していないことを確認できます。

関連する問題