偽のリポジトリをテストする意味は何ですか？

Question

自宅で開発するときは、TDDと少しDDDにもっと合わせられるように、自分のメンタリティを高めようとしています。

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

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

Answer 1

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

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

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

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

Answer 2

ご覧のとおり、偽造されたリソースに対してテストする理由は2つあります。

• 遅いI / Oまたはデータベースに対してモックアップされている場合、ユニットテストをより高速にします。小さなテストスイートがある場合、これは何のようにも見えないかもしれませんが、最大+500のユニットテストを実行すると、違いが生じ始めます。そのような量では、データベースに対して実行されるテストの実行には数秒かかります。プログラマーは怠け者であり、物事を高速化したいので、テストスイートの実行に10秒以上かかる場合は、TDDを実行することはもうありません。
• 変更を容易にするために、コード設計について考えることを強制します。インターフェースや抽象クラスに対する実装を行った場合、コントラクトと依存性注入による設計も非常に簡単になります。適切に設計されていれば、このような設計によりコードの変更に簡単に準拠できます。

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

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

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

Answer 3

Giraffeの答えを支持しましたが、いくつかのポイントを追加したいだけです。

• 各開発者はモック/フェイクを使用できます 彼女/彼自身のユニットのリポジトリ に干渉することなくテスト 他の開発者によって行われているテスト 同じプロジェクトに。

• ローカルのモック/偽のリポジトリを使用する データのユーザーを強化します 優れた抽象化レイヤー デザインプラクティス。

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