9

自宅で開発するときは、TDD と少しの DDD に向けて自分の精神を押し上げようとしています。

私が理解できないことの 1 つは、テスト用に偽のリポジトリを作成する理由です。私はあまり詳しく調べていませんが、テストのアイデアは、コードを切り離し (柔軟性を高める)、必要なコードを削減し、バグの数を減らすことです。

それでは、誰かが偽のリポジトリをテストするのが好きな理由について、私の愚かな頭脳に記入してもらえますか? 実際のデータベースに対してテストすることは、偽のデータベースを作成するよりもはるかに優れた代替手段であると考えていました。なぜなら、それが実際のデータストアに対して機能することがわかっているからです。

4

3 に答える 3

22

偽のリポジトリを使用すると、アプリケーション コードだけをテストできます。

偽のリポジトリとは、自動化されたテストがリポジトリ内の既知の状態を簡単に設定できることを意味します。

偽のリポジトリは、実際のデータベースより数桁高速です。

偽のリポジトリは、データベースを含むシステム テストの代わりにはなりません。

于 2009-01-02T13:05:19.937 に答える
7

私が見ているように、偽造されたリソースに対してテストするのには、2 つの非常に大きな理由があります。

  • 低速の I/O またはデータベースに対してモックアップを作成すると、単体テストが高速になります。小さなテスト スイートの場合、これは何のようにも見えないかもしれませんが、ユニット テストが 500 以上になると、違いが出始めます。そのような量では、データベースに対して実行されるテストの実行に数秒かかり始めます。プログラマーは怠け者で、物事が速く進むことを望んでいるため、テスト スイートの実行に 10 秒以上かかる場合は、TDD を実行することに満足できなくなります。
  • 変更を容易にするために、コード設計について考える必要があります。インターフェイスまたは抽象クラスに対して実装を行った場合、契約による設計と依存関係の注入も非常に簡単になります。このような設計が正しく行われていれば、コードの変更に簡単に準拠できます。

唯一の欠点は明らかなものです。

  • それが本当に機能することをどのように確認できますか？

...そしてそれが統合テストの目的です。

于 2009-01-02T13:18:11.237 に答える
2

私はキリンの答えに賛成しましたが、いくつかの点を追加したいと思います:

  • 各開発者は、同じプロジェクトで他の開発者が行っているテストに干渉することなく、自分の単体テストにモック/偽のリポジトリを使用できます。

  • ローカルのモック/フェイク リポジトリを使用すると、データ抽象化レイヤーのユーザーが強化されます。これは優れた設計手法です。

HashMap例として、データ アクセス レイヤーのモックを実装するためにのような単純なものを使用しました。これにより、各単体テストで、その目的に必要な条件が正確に存在することを確認し、データ アクセス レイヤーで正しい呼び出しが行われたことを確認することが非常に簡単になります。

于 2009-01-02T14:28:01.000 に答える