unit-testing - 偽のクラスを作成して単体テストする必要があるのはなぜですか?

Question

実際のクラスをテストできるロジックを持つクラス (たとえば、割引を計算できるクラス) をテストする必要があることは理解しています。

しかし、リポジトリとして機能する (データベースからオブジェクトを取得する) プロジェクトの単体テストを書き始めたところです。ISomethingRepositoryインターフェイスを実装する「偽の」リポジトリを作成していることに気づきました。Dictionary<Guid, Something>内部ストレージにを使用します。Add(Something)インターフェイスのおよびGetById(Guid)メソッドを実装します。

なぜ私はこれを書いているのですか？私が書いているものは、ソフトウェアが展開されたときに実際にソフトウェアによって使用されることはありませんよね? この演習の価値がよくわかりません。

また、特定の期待に応えるために事前にセットアップできるモックオブジェクトを使用するようアドバイスも得ました。それは私にはさらに無意味に思えます: もちろん、テストは成功します。私はそれを嘲笑/偽造して成功させました! そして、データベースに接続するときに実際のソフトウェアが正常に動作するかどうかはまだわかりません...

混乱している...

これを理解するのを助けるために誰かが私を正しい方向に向けることができますか?

ありがとうございました！

score 14 · Accepted Answer

モックオブジェクトをテストしているのではなく、モックオブジェクトと相互作用している他のクラスをテストしています。したがって、たとえば、コントローラーがsaveメソッド呼び出しを偽のリポジトリーに転送することをテストできます。「偽のオブジェクトをテストしている」場合は、何か問題があります

score 4 · Accepted Answer

モッククラスをテストしないでください。モッククラスを使用して本番クラスをテストしてください。

テストサポートクラスの要点は、その動作を予測できるものを用意することです。動作を予測するためにテストサポートクラスをテストする必要がある場合は、問題があります。

コメントでリンクした偽のデータベースの記事では、作成者は自分の製品であるため、偽のデータベースを単体テストする必要があります（少なくとも記事のコンテキストでは）。

編集：より一貫性のあるように用語を更新しました。

モック-モックフレームワークによって作成されました
偽物-手動で作成され、実際に機能する場合があります。
テストサポート-モック、フェイク、スタブ、その他すべて。生産ではありません。

score 2 · Accepted Answer

モック/スタブオブジェクトの目的は、テストしようとしているユニットの代わりにテストすることではなく、他のクラスを必要とせずにそのユニットをテストできるようにすることです。

これは基本的に、クラスが依存しているすべてのクラスをテストする必要なく、一度に 1 つずつクラスをテストできるようにするためです。

score 1 · Accepted Answer

自分で偽のクラスを作成する代わりに、ツール（RhinoやTypemockなど）を使用してそれをモックすることができます。すべてのモックを自分で書くよりもはるかに簡単です。そして、他の人が言ったように、偽のコードをテストする必要はありません。これは、ツールを使用する場合はコードではありません。

score 1 · Accepted Answer

守護神伝説は誰ですか？

たとえば、モック実装がコーナーケースに対して特定の例外をスローする場合は興味深いので、IRepositorySomethingを使用または依存するクラスは、実際にスローされる例外を処理できることがわかります。これらの例外のいくつかは、テストデータベースでは簡単に生成できません。

単体テストでモックオブジェクトをテストするのではなく、それに依存するクラスをテストするために使用します。

score 1 · Accepted Answer

私は実際に、リポジトリの実装テストで使用するモッククラスの用途を 2 つ発見しました。

1つ目は、言及した「ISomethingRepository」に相当する実装を使用するサービスをテストすることです。ただし、リポジトリの実装はファクトリによって作成されます。これは、「MockSomethingRepository」に対して直接ではなく、「ISomethingRepository」に対してテストを作成することを意味します。インターフェイスに対してテストすることで、テストのコードカバレッジがインターフェイスの 100% をカバーしていると簡単に断言できます。コードレビューでは、新しいインターフェイスメンバーがテストされていることを簡単に確認できます。開発者がファクトリが返すモックに対して実行している場合でも、ビルドサーバーには、ナイトリービルド内でファクトリが返す具体的な実装に対してテストする別の構成があります。これは、テストカバレッジとローカルパフォーマンスの点で、両方の長所を提供します。

2 番目の用途は、他の誰も言及していないことに驚いています。私のチームは中間層を担当しています。当社の Web 開発者は、Web 製品のフロントエンドを担当しています。モックリポジトリの実装を構築することにより、フロントエンドの作業を開始する前に、データベースがモデル化されて実装されるのを待つという人為的な障害がなくなります。Web 開発者の期待に応えるために、最小限の「実際の」データを提供するためにモックから構築されるビューを作成することもできます。たとえば、最小長と最大長の文字列データを含むデータを提供して、実装が壊れていないことを確認できます。

私たちが使用するファクトリは、どの「ISomethingRepository」が返されるかについて配線されているため、ローカルテスト構成、ビルドテスト構成、運用構成などがあります。別のチームの実装時間。待機時間の最大の部分は依然として開発チームによって提供されますが、フロントエンド開発よりも速いペースでドメインオブジェクト、リポジトリ、およびサービスを開始できます。

もちろん、YMMV。;-)

score 1 · Accepted Answer

モッククラスをテストするべきではありません。

通常行うことは、テスト対象のクラスが対話するすべてのクラスのモッククラスを作成することです。

Wheel、Saddle、HandleBar などのクラスのコンストラクターオブジェクトを受け取るBicycleというクラスをテストしているとします。

次に、Bike クラス内でテストしたいメソッドGetWeightをテストします。このメソッドは、おそらく各部分を反復処理し、それらのプロパティ/メソッド Weight を呼び出してから、合計を返します。

あなたがすること：

単純に Weight ビットを実装する各パーツ (ホイール、サドルなど) のモッククラスを作成します。
次に、それらのモッククラスを Bicycle に渡します
Bicycle クラスでGetWeightメソッドをテストする

そうすれば、他のクラスから独立した方法で (まだ実装されていない、決定論的ではないなど)、Bicycle クラスでGetWeightをテストすることに集中できます。

score 0 · Accepted Answer

通常、データアクセス層で従来の単体テストを実行する必要はありません。おそらく、ユニットテストフレームワークの機能を使用して、データアクセスクラスの統合スタイルのユニットテスト、つまり統合テスト (= データアクセス層コードを DB に統合すること) を作成できます。

たとえば、Spring プロジェクトでは、Spring Testcontext を使用して単体テスト内で Spring コンテキストを開始し、実際のデータベースに接続して、クエリが正しい結果を返すことをテストできます。おそらく、単体テスト用に独自のデータベースが必要になるか、それらを開発者 DB に接続することができます。

score 0 · Accepted Answer

実際の具体的なクラスをテストせずに簡単な方法で実装をテストしたいので、スタブまたはモックオブジェクトと呼ばれる「偽の」クラスを作成します。目的は、インターフェイス (または抽象クラス) のみをテストすることにより、テストを簡素化することです。

あなたの例では、辞書を持つものをテストしています。データベースによって実際にいっぱいになるか、背後に多くのロジックがある可能性があります。「偽の」オブジェクトでは、すべてのデータを一定にすることですべてを簡素化できます。このようにして、具象オブジェクトの構築方法ではなく、インターフェイスの動作のみをテストします。

unit-testing - 偽のクラスを作成して単体テストする必要があるのはなぜですか?

10 に答える 10

Related

Reference