4

私は TDD に従おうとしていますが、小さな問題に遭遇しました。新しいユーザーをデータベースに挿入するテストを作成しました。Insert new user は MyService クラスで呼び出されるため、先に進み、mytest を作成しました。失敗したので、MyService クラスに CreateUser メソッドを実装し始めました。

私が遭遇している問題は、データベースの挿入を行うために MyService がリポジトリ (別のクラス) を呼び出すことです。

そこで、モック フレームワークを使用してこの Repository クラスをモックアウトしようと考えましたが、これは正しい方法でしょうか?

これは、ユーザー リポジトリのモックを実際に作成するには、テストを変更する必要があることを意味します。しかし、これはお勧めですか？最初にテストを作成して失敗させましたが、今ではリポジトリが必要であり、それをモック化する必要があることに気付きました。そのため、モック化されたオブジェクトに対応するようにテストを変更する必要があります。少し臭い？

ここでフィードバックをいただければ幸いです。

これが正しい方法である場合、実際のユーザー リポジトリはいつ作成しますか? これには独自のテストが必要ですか？

それとも、何かを嘲笑することを忘れるべきですか？ただし、MyService とユーザー リポジトリを 1 つのユニットとして一緒にテストすることになるため、これは単体テストではなく統合テストとして分類されます。

私は少し迷った。正しい方法で始めたい。

4

4 に答える 4

6

そこで、モック フレームワークを使用してこの Repository クラスをモックアウトしようと考えましたが、これは正しい方法でしょうか?

はい、クラスを分離してテストする必要があるため、これは完全に正しい方法です。つまり、すべての依存関係をモックすることによって。そうしないと、クラスが失敗したのか、その依存関係の一部なのかを判断できません。

最初にテストを作成して失敗させましたが、今ではリポジトリが必要であり、それをモック化する必要があることに気づきました。そのため、モック化されたオブジェクトに対応するようにテストを変更する必要があります。少し臭い？

クラスの抽出、メソッドの再編成などはリファクタリングです。そしてテストは、リファクタリングを支援し、変化への恐れを取り除くためにここにあります。実装が変更された場合、テストを変更するのはまったく普通のことです。最初の試みから完璧なコードを作成し、それを二度と変更できないとは思わなかったと思いますか?

これが正しい方法である場合、実際のユーザー リポジトリはいつ作成しますか? これには独自のテストが必要ですか？

アプリケーションに実際のリポジトリを作成します。また、このリポジトリのテストを作成できます (つまり、モック化する必要がある、基礎となるデータ アクセス プロバイダーを正しく呼び出すかどうかを確認します)。しかし、そのようなテストは通常​​、非常に時間がかかり、脆いものです。そのため、実際のリポジトリを使用してアプリケーション全体を実行するいくつかの受け入れテストを作成することをお勧めします。

それとも、何かを嘲笑することを忘れるべきですか？

まったく逆です。クラスを分離してテストするには、モックを使用する必要があります。モックに多くの作業 (データ アクセス、UI) が必要な場合は、そのようなリソースをモックせず、統合または受け入れテストで実際のオブジェクトを使用します。

于 2013-06-25T16:31:40.933 に答える
1

データベースへの依存関係をモックアウトしてから、モックで期待されるメソッドを呼び出すサービスをアサートすることは間違いありません。ベスト プラクティスに従おうとしている皆さんを称賛し、この道を歩み続けることをお勧めします。お気づきのように、作業を進めていくと、作成するクラスに新しい依存関係を追加し始めることになります。インターフェイス IUserRepository を作成する場合のように、これらの依存関係を外部で満たすことを強くお勧めします。これにより、モックを作成し、IUserRepository をサービスのコンストラクターに渡すことができます。次に、これをインスタンス変数に格納し、必要なメソッド (つまり、_userRepository.StoreUser(user)) を呼び出します。その利点は、テスト クラスからこれらの依存関係を満たすことが非常に簡単であり、オブジェクトのインスタンス化について心配できることです。

tl;dr: モックを作成してください!

于 2013-06-25T16:26:45.930 に答える
0

あなたの最初のテストは不完全でした、それだけです。最終テストでは常に、新しいユーザーが永続化されるという事実に対処する必要があります。

TDD では、作成する必要があるテストの種類は規定されていません。単体テストにするか、ある種の統合テストにするかを事前に選択する必要があります。単体テストの場合、モックの使用は実質的に避けられません (テスト対象のユニットに分離する依存関係がない場合を除きます)。統合テストの場合は、実際のデータベース アクセス (この場合) をテストで考慮する必要があります。

どちらの種類のテストも正しいです。大規模なユニット テスト スイートを作成してユニットを分離してテストし、別の小さなテスト スイートでユース ケース シナリオ全体を実行するというのが一般的な考え方です。

于 2013-06-27T13:05:51.750 に答える