データベースからデータを取得する機能を使用し、表示/解析/等の結果を返すWebサイトがあるとします。動的データに依存する関数の単体テストの記述方法？
データベースから取得されるデータは動的であり、潜在的に毎日変化しますが、この関数の単体テストをどのように正しく記述しますか？
関数が結果の配列を返すと仮定します。明らかに、ユニットテストは、配列が返されるかどうかを調べるためにテストすることができます。しかし、誤って書かれたMySQLクエリのために、配列自体の内容が正しくないとどうなりますか？配列のサイズがゼロであるか、配列の内容が正しくない可能性があります。それは絶えず変化するデータに依存しているため、単体テストはどのようなものが正しいのか、そうでないのかを知ることができますか？単体テストそのものからデータベースへの呼び出しが必要なので、それを比較する何かがありますか？
ダイナミックデータに依存する関数の単体テストを正しく記述するにはどうすればよいですか？
単体テストは、理想的な形では1つだけテストするべきです。
は、だから私は、次のリファクタリングを示唆しているデータベース検索は、あなたの関数のロジック：
また、一般的にそれはあなたが、データベースに格納されているものを完全に制御を持っているテスト環境でユニットテストを実行することをお勧めします。これらは実動データに対して実行したくありません。
良い点。したがって、検索されたデータが正しいかどうかではなく、データ検索機能のロジックのみをテストする必要があると言っていますか？また、私たちの開発環境では、通常、我々は最近のデータを扱うために、ライブDB - > dev DBの一方向の同期を行います。いずれの場合でも、データは依然として動的です。ありがとう。 –
ユニットレベルでは、私がdbに書き込むロジックが正しいこと、そして自分の読んだことのためのロジックが正しいことをテストする方が好きです。私が構築したカスタムORMを使用していない限り、データベースに対してSQLの単体テストを行う必要はありません。次に、私は通常、自分のデータが私が期待するものであることを示す機能テストまたは統合テストを作成します。テスト以外のもので更新されていないdbに対してこれらを実行します。ダイナミックなデータを使って実世界のシナリオをシミュレートすることは、統合（およびパフォーマンス）テストではうまくいきますが、システムに対する信頼性は他のものからのものでなければなりません。 –
どのように機能を模擬しますか？ –
本当にできません。信頼できる単体テストを作成するには、保証された静的データセットが必要です。データベースのスナップショットが役立つかもしれません。
動的データは
ほとんどのテストでは、データを取得するようなものに関与しているの論理パスに焦点を当てる...回帰テストを実行するなど、他の方法に有用であることができます。データそのものの有効性ではありません。データの妥当性は、アプリケーションが何らかの形で計算または集計している場合にのみ意味があります。その場合は、入力を制御して結果が正しいことを確認できる必要があります。
これは、アプリが返品を確認するために使用しているのと同じデータベースをヒットしたいと思うことがあります。たとえば、フィルタリングされたデータセットを返す関数をテストする場合、単体テストで同じクエリを実行し、各レコードの主キーの行ごとの比較を行い、関数があなたが期待していたのと同じ一連のデータ
これがあなたの特定の質問であるかどうかわかりませんが、逆に単体テストでアサーションを実行するためにデータベースにヒットしても問題ありません。少なくとも私はいつもそれを行い、誰も私を逮捕しようとしていません:)
あなたがDBについて話しているという事実を無視して、私はあなたが単位減量をカバーするためにそれが減っているリターンにつながる可能性がある場所をカバーしているかもしれないと思います。もし私があなただったら、私は標準的な道をカバーし、次にいくつかの縁の場合をカバーします。事実、すべてを実用的にテストすることはできません。
ここではいくつかは、さらに
あなたはおそらくpoulateデータを事前に seamを作成する必要があり、この機能をテストするために、あなたのspecifcデシベル関連の問題を見てみるとhttp://37signals.com/svn/posts/3159-testing-like-the-tsa
How deep are your unit tests?
http://johnnosnose.blogspot.co.uk/2012/04/re-over-testing.html
http://martinfowler.com/bliki/TestCoverage.html
を読んでいますこれらのケースをカバーすることができます。
Heh私の経験では、ほとんどのバグはテストするのが難しい分野に精密に入り込みます。したがって、テストフレームワークに時間を投資することで本当に恩恵を受けるのはこれらの分野だけです。実際にx、y、zが本質的にテスト可能でないという特性によって定義されている場合、マネージャーは確かに、私は確信しており、「x、y zの単体テストが必要」と考えています。これらの理由から、私は単体テストを、最も固く、非機敏なUMLベースのOOPプラクティスよりも柔軟性が低いと考えています。 1時間に作業する独創的な開発者として、それは本当に銀色の弾丸の仕事です。 –
あなたの関数がデータベースからデータを引き出すこと以外に面白いことをしている場合、検索を別の関数に抽出してモックして残りの部分をテストする必要があります。
これでも、データベースアクセスをテストする作業が残っています。定義されているデータベースにアクセスするのではなく、SQL文が実際に動作するかどうかを確認するSQL文を送信するかどうかをテストするだけで、単体テストを行うことはできません。
だからあなたは、様々なoptiones持つデータベース
が必要になります。
1）をテストすることによって変更されないようなテストのために固定されたデータベースを作成します。
プロ：概念的に簡単 Con：維持しにくい。テストは同じデータに依存しているため、相互依存関係になります。更新、挿入、または削除を行うものをテストする方法はありません（DDLはもちろん）
2）テスト中にデータベースを作成します。ここでは、テストのためのデータベースの設定とデータの入力という2つの問題があります。
設定：
1）テスト（少なくとも開発者+ CI-server）を実行する必要があるerveryoneためのユーザー/スキーマ/データベースと、データベース・サーバを実行しています。スキーマは、hibernateやデプロイメントに使用するスクリプトを使用して作成できます。
素晴らしい作品ですが、古いファッションモデルのDBAを狂ってしまいます。アプリケーションは、スキーマ名に依存してはいけません。また、アプリで複数のスキーマが使用されている場合にも問題が発生します。この設定はかなり遅いです。それは速いディスクに置くのを助けることができます。 RAMディスクのように
2）メモリデータベースがあります。簡単にコードから始めることができます。しかし、ほとんどの場合、本番データベースと同じように動作します。違いを隠そうとするものを使用すると、これはあまり問題になりません。私はしばしば、最初のビルド段階ではメモリ内のデータベースを使用し、2番目の段階では実際のものを使用します。
テストデータ
1）人々はDbUnitをを使用するように私に言うのロード。私はそれがXMLの数が多く、列や制約が変わったときに維持するのが難しいと確信していません。
2）私は通常のアプリケーションコードを好む。 （Java + Hibernate）を使用していますが、多くの場合、テスト用のテストデータを書くのに適しているはずです。 http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and-hibernate-part-1-one-to-rule-them/
私はテストそのものにデータを構築します。これは、外部キーとすべてのものを満たすための詳細を隠す少し特殊なAPIを持つのに役立ちます。そうすれば、常に変化するデータの複雑なシナリオをテストすることさえできます。重要な点は、専用テストDBを使用することで、テストのデータ変更を制御できることです。 ステップ2：dbは、テストでのみ使用されるdbに必要なデータを挿入します。今すぐ安定した予測可能な状態になるので、クエリを実行して出力をテストすることができます
これは興味深いかもしれません：http://blog.schauderhaft.de/2011/03/13/testing-databases-with-junit-and -hibernate-part-1-one-to-rule-them/ –