私は、ユニットテストが実行されたときにデータベースにヒットしてはならないというブログを読んだ。私は理論を理解していますが、私はビジネスドメイン操作の一部である複雑なストアプロシージャを持っていると言います。私はビジネスオペレーションに関連するコードのための単体テストのセットを書こうと思っていますが、私がデータベースを偽装すると、実際にはオペレーションの一部であるすべての部分を "本当に"テストしていないという気持ちがあります。たとえば、誰かがデータベースコードのいずれかにバグを作成する可能性があり、テストは引き続きOKです。ユニットテストでデータベースにヒットしないのはなぜですか？
単体テストに関するこのガイドラインが実際に良好かどうかを知りたいと思います。 私は "統合テスト"という概念を見てきましたが、統合テストを行うためにどのツールを使うべきかについてはわかりません。例えば、Nunitのようなテストフレームワークを使って統合テストを作成するのはいいですか？
おかげ
ヒューゴ
は、あなたは、単にセマンティック灰色の領域です。
その場合、アプリケーションコードの単体テストは/データベースにヒットしない場合がありますでしょうが、あなたは/あなたのデータベースのストアドプロシージャをカバーしたユニットテストを持っている可能性があるでしょう...
基本的にあなたのアプリケーションを分割意味のあるパーティションに沿ってテストされるもの。間違ったパーティションラインを選択した場合は、モックオブジェクトやテスト用の足場などで大きなコードのメンテナンスの問題が発生します...
ウェブアプリケーションとの共通のやり方は、データアクセスをテストする一連の単体テスト層... THEN
...
（データ層を含む）は、アプリケーション層のテストユニットの一連のテストを記述し、最後にいくつかのブラウザベースのシステムテストを書く...
トリックは、APIを介して中間セット（アプリケーションレイヤー）に情報を入れたり出したりするだけです。データベースが何か働いているかどうかを確認します。そうすれば、データスキーマを変更してもテストは中断されません。
しかし、時には（実際に私がこれを書いているように）あなたは意味のある堅牢なテストスイートを作るためにデータベースを調べなければなりません（私はサーバ - サーバ転送プロトコルをテストしています）。
あなたのアプリケーションで最大限のコードカバレッジと安定性を得る方法に焦点を当て、テスト用足場の量を最小限に抑え、テストスイートでの脆さを避けます。
あなたのテストでデータベースをadressingでの問題は、データベースの変更またはコードの変更がテストに失敗することができるということです。単体テストは、通常、彼が失敗させた変更に可能な限り直接的に指すべきです。 DBアクセスのコードをテストしたいのであれば、固定テストデータベースを使用することもできます。このようにして、データベースにアクセスしたコードが間違っていることがわかります。データベースが変更されていないことがわかっているため、DB設定を変更したい場合はテストDBを最初に変更し、テストDBではありません。 私が勤めたプロジェクトでは、各テストの前にメモリに生成された小さなデータベースを作成しました。
"ユニットテストの実行時にデータベースをヒットしないでください..." - もちろん、永続オブジェクトをユニットテストしている場合を除きます。
私はどのブログを引用しているのか分かりませんが、統合テスト中に一部のコンポーネントを嘲笑することはメリットがあると言います。すでにパーシスタンス層を単体テストしている場合は、それを再度テストする必要はありません。そのような場合の嘲笑の利点は、依存関係や不確実性を減らすことと関連があります。たとえば、単体テストにコードをパッケージ化してパッケージ化して、今すぐ、それを実動環境に近い環境に移動するときです。必要なデータベースが利用できない場合（たとえば、適切なバージョンのスキーマがない、必要なデータがない、または最初に取得した別のアプリケーションが必要とする場合など）、mockを使用して統合できます遅滞なくテストを進めてください。
あり、データベースをhitingないユニットテストのための2つの主な理由です：
あなたのケースでは、ストアドプロシージャをテストする必要があります。次に、それらのストアドプロシージャを実行するテストを作成する必要があります。あなたのコード（統合テスト）を介して実行することも、テストから直接実行することもできます（単体テストの一種）。どちらの場合も、Nunitを使用できます。
あなたのunittestsがデータベースにヒットした場合は、単なるコード単位をテストするのではなく、DALやストアドプロシージャなどを打つことになります。 TDD支持者はユニットテストでデータベースにヒットしないと言います。
そのまた、なぜあなたは理論上、TDD-概念、純粋な聖なるU NIT TのESTに多くの重量を保持するはずの。 unittesting自体は悪いことではありませんが、プログラマが各コンポーネントを適切に構築するためには、実際には非常に重要です。システムテストはもっと重要です。全体として、システムテストが失敗する原因となった正確な方法を見つけるのは難しいかもしれません。より現実的であり、は実際にシステムをテストします。
システムテストに似ていますが、システムのわずかな部分だけエンドツーエンドのいわゆる「コンポーネントテスト」が私には良い妥協と思われます。
（今TDDの反論を頭出し... :)）
Should one test internal implementation, or only test public behaviour?と書いて、人々の回答を議論した後、答えは開発チームの人の人数によって異なると思います。データベースとテストの
利点：
短所：
であるかどうかわからない
YMHOここでは意味論的な問題と少しの技術的な問題があります。
単体テストは、小さなコードを別のコードでテストして、別のコードなしでチェックすることになっています。ユニットテストが失敗した場合は、コードのほんの一部のみを修正しなければならないことを意味するはずです（基本的に、機能を実装するコードと単体テスト自体）。
システム全体の機能（システムテスト）、完全な機能を検証するための機能テスト、または相互作用をチェックする統合テスト、すでに訂正されたテストなどがないかどうかを確認するための回帰テストなどがあります。
プロジェクトごとにテスト戦略を策定する必要がありますが、一般的には異なるカテゴリを持つことで多くの助けになります。だからユニットテストはコードの最小可能単位のテストに制限し、機能をテストするために、他の試験手順を使用しなければならない、統合等
セマンティック部分は正しいを実行するユニットテストライブラリを使用するかどうかでありますいくつかの機能テスト、私はあなたがあなたのスイートを分離しておくと、それは大したものではないと思います。（彼らがテストツールを共有していても）厳密なユニットテストと機能テストを共有しても。
まったく同じこと。私たちのQ/Aグループに！彼らは1つの大きなテストを見て、時には依存関係があることを理解していないことがあります。 私は幾分か形を外して同じレコードを複数回追加することはできませんでした。それで私は彼らにテストにセットアップとティアダウンの部分を追加する必要があることを彼らに納得させなければなりません。 （DAREプログラマー/デザイナーが、テストの書き方を教えてくれる方法） –
あなたのテストを書くのはすばらしいです（個人的にはテストが大好きですが） – Chazt3n