私は利点が何であるかを知っており、より複雑なシステムで作業しているときに偽のデータを使用しています.
単純なものを開発していて、実際のデータベースに環境を簡単にセットアップでき、アクセスされるデータが非常に小さいためアクセス時間が問題にならず、いくつかのテストしか実行していない場合はどうなるでしょうか。
偽のデータを作成することはまだ重要ですか、それとも余分なコーディングを忘れて本物にスキップできますか?
私が実際のデータベースと言ったとき、それは本番データベースを意味するのではなく、テストデータベースを意味しますが、実際のライブ DBMS と実際のデータベースと同じスキーマを使用しています。
実際の DB の代わりに偽のデータを使用する理由は次のとおりです。
ここで、小規模なアプリケーションを構築していて、実際の DB (MySQL など) を使用することで上記の目標を達成できる場合は、ぜひ DB を使用してください。そうです。ただし、間違いなく、アプリケーションが成長するにつれて、最終的には DB をモックアウトする必要に直面することになります。いいから、必要なときにやればいい。ヤグニ。必要なときに必ず実行してください。放っておくと支払いが発生します。
クエリがリポジトリ内で修正されているかどうか (より良いオプション、IMO)、またはリポジトリが構成可能なクエリを公開しているかどうかに依存すると思います。例-リポジトリメソッドがある場合：
IQueryable<Customer> GetCustomers() {...}
次に、UI は次のように要求できます。
var foo = GetCustomers().Where(x=>SomeUnmappedFunction(x));
bool SomeUnmappedFunction(Customer customer) {
return customer.RegionId == 12345 && customer.Name.StartsWith("foo");
}
これは、オブジェクト ベースの偽のレポでは成功しますが、実際のdb 実装では失敗します。もちろん、リポジトリにすべてのクエリを内部で処理させることでこれを無効にすることができます (外部構成はありません)。例えば：
Customer[] GetCustomers(int? regionId, string nameStartsWith, ...) {...}
これは構成できないため、DB と UI を個別に確認できます。構成可能なクエリを使用すると、統合テストを有効にしたい場合は、全体で統合テストを使用する必要があります。
それは、何をテストしたいかによって異なります。多くの場合、データベース内のデータではなく、コード内の実際のロジックをテストしたいため、テストを実行するためだけに完全なデータベースをセットアップするのは時間の無駄です。
また、テストとテストデータベースの維持にかかる作業量も考慮してください。データベースを使用してコードをテストすることは、多くの場合、さまざまな部分を分離してテストするのではなく、アプリケーション全体をテストすることを意味します。これにより、多くの場合、データベースとテストの両方を同期させるために多くの作業が必要になります。
そして最後の問題は、テストを独立して実行する必要があるため、各テストを独自のバージョンのデータベースで実行するか、テスト実行前とまったく同じ状態のままにしておく必要があることです。これには、失敗したテストの後の状態が含まれます。
そうは言っても、本当にデータベースでテストしたい場合はできます。dbunitなど、データベースのセットアップと破棄を支援するツールがあります。
このような単体テストを作成しようとしている人を見てきましたが、ほとんどの場合、実際の価値よりもはるかに多くの作業が必要になります。ほとんどの人は、プロジェクトの途中で ttd を放棄し、プロジェクトの途中で ttd を完全に放棄しました。
したがって、テストをシンプルかつ分離した状態に保ち、コードを十分にカプセル化して、コードを分離してテストできるようにすることをお勧めします。
Real DB が邪魔にならず、その方法でより速く進むことができる限り、私は現実的であり、それを選びます。
単体テストでは、「単体」よりも「テスト」が重要です。
それはむしろ、DBがテストによって自動的にセットアップされるかどうか、またデータベースが他の開発者から分離されているかどうかに依存します。
現時点では問題にならない可能性があります（たとえば、開発者が1人だけ）。ただし、（データベースを手動でセットアップする場合）データベースをセットアップすることは、テストを実行する上での追加の障害であり、これは非常に悪いことです。
絶対に成長しないことがわかっている単純な1回限りのアプリケーションを作成しているだけの場合は、多くの「ベストプラクティス」がすぐに利用できると思います。
単純な「お問い合わせ」フォームを作成するだけであれば、DI / IOCを使用したり、単体テストを行ったり、データベースアクセスをモックアウトしたりする必要はありません。ただし、「単純な」アプリと「複雑な」アプリの間に線を引くのは困難です。
言い換えれば、これに対する明確な答えはないので、あなたの最善の判断を使用してください。
これを自動化する場合、最も重要なことは、プログラムで初期条件を生成できることです。そのように聞こえますが、実際のデータをテストしている方がよいでしょう。
ただし、いくつかの欠点があります。
実際のデータベースは、コード内の特定の条件をカバーしていない可能性があります。偽のデータがある場合は、その動作が発生します。
そして、あなたが指摘するように、あなたは単純なアプリケーションを持っています。単純さが少なくなった場合は、単体テストとシステムテストに分類できるテストが必要になります。単体テストは、偽のデータを使用する方がはるかに簡単な単純な機能を対象にする必要があります。
それらを「単体」テストと見なさない限り、シナリオでそれを行っても問題ありません。それらは統合テストになります。また、代わりにスモーク テストを自動化する可能性があるため、UI を使用して何度も手動でテストするかどうかも検討する必要があります。そのため、統合テストをまったく行わず、機能/UI テスト レベルで作業することを検討することもできます (統合は既にカバーされているため)。
他の人が指摘したように、複雑/非複雑で線を引くのは難しく、通常、手遅れになるとすぐにそうなるでしょう:(。すでにそれらを行うことに慣れている場合は、あまり得られないと確信していますそうでない場合は、そこから学ぶことができます:)
データベースに対してテストを実行することの欠点は、テストを実行する前にデータベースの状態を設定する速度と複雑さが不足していることです。
これを制御できる場合は、データベースに対して直接テストを実行しても問題はありません。偽のデータに対して実行するよりも最終製品をより適切にシミュレートするため、実際には優れたアプローチです。重要なのは、実用的なアプローチを取り、ベストプラクティスをルールではなくガイドラインと見なすことです。
偽のリポジトリの利点の 1 つは、同じクエリに対して同じ結果が期待できるため、回帰/単体テストが一貫していることです。これにより、特定の単体テストの作成が容易になります。
コード (読み取りクエリのみではない場合) がデータを変更する場合、いくつかの欠点があります。壊さなくても。- 運用データベースが時間の経過とともに、特にコードの実行中に変更された場合、追加したテスト マテリアルを追跡できなくなり、後でデータベースからクリーンアップするのに苦労する可能性があります。- データベースにアクセスする他のシステムからの本番クエリは、テスト データを実際のデータとして扱う可能性があり、重要なビジネス プロセスの結果がどこかで破損する可能性があります。たとえば、データに特定のフラグや接頭辞を付けたとしても、データベースにアクセスするすべての人がこのスキーマに従うことを保証できますか?
また、一部のデータベースはプライバシー法によって規制されているため、契約とメイン DB の所有者によっては、実際のデータへのアクセスが法的に許可される場合と許可されない場合があります。
運用データベースで実行する必要がある場合は、ピーク時に簡単に作成できるコピーで実行することをお勧めします。
これは非常に単純なアプリケーションであり、実際の DB でテストを実行しても問題はありません。ただし、このアプリケーションが成長すると思われる場合は、テストでそれを考慮することが重要です。
すべてをできるだけシンプルに保ち、後でより柔軟なテストが必要な場合は、そうしてください。ただし、古くてハッキーな (大規模なアプリケーションの場合) テストに依存する巨大なアプリケーションを 3 年以内に作成したくないため、事前に計画してください。