9

私はいつもこの混乱を抱えています。偽のコードを使用して何らかの操作をアサートするコードを作成した場合、偽のオブジェクトではなく実際のオブジェクトを使用して実際に開始されたときに、実際の実装を信頼するにはどうすればよいですか。

たとえば、私はこのコードを持っています -

    [Test]
    public void CanCreateContactsWithData()
    {
        using(ISession session = factory.OpenSession())
        using (ITransaction trans = session.BeginTransaction())
        {
            _contactId = (long) session.Save(contact);
            trans.Commit();
        }

        Assert.AreNotEqual(0, _contactId);
    }

このコードは、データベースに保存されるかどうかに関係なく、「連絡先」オブジェクトの実装をテストします。たまたま実際のデータベース接続の代わりにスタブを使用した場合、それをデータベースに格納するための別のテストが必要ですか? そして、あなたはそれを統合テストと呼んでいますか?

回答をお待ちしております。

4

5 に答える 5

18

Martin Fowler はここで良い議論をしています。

彼の記事から：

Meszaros は、Test Double という用語を、テスト目的で実際のオブジェクトの代わりに使用されるあらゆる種類のふりをしたオブジェクトの総称として使用しています。名前は、映画のスタント ダブルの概念に由来します。(彼の目的の 1 つは、すでに広く使用されている名前を使用しないようにすることでした。) 次に、メザロスは 4 つの特定の種類の double を定義しました。

  • ダミー オブジェクトは渡されますが、実際には使用されません。通常、これらはパラメーター リストを埋めるためにのみ使用されます。
  • 偽のオブジェクトには実際に機能する実装がありますが、通常は本番環境には適していないショートカットを使用します (メモリ内データベースが良い例です)。
  • スタブは、テスト中に行われた呼び出しに対して定型の回答を提供します。通常、テスト用にプログラムされたもの以外にはまったく応答しません。スタブは、「送信した」メッセージや、「送信した」メッセージの数だけを記憶する電子メール ゲートウェイ スタブなど、呼び出しに関する情報も記録する場合があります。
  • ここで話しているのはモックです。つまり、受け取ると予想される呼び出しの仕様を形成する期待値で事前にプログラムされたオブジェクトです。

これらの種類の double のうち、動作の検証を主張するのはモックだけです。

于 2009-08-17T16:10:24.713 に答える
3

関数が何らかの値を返す (または何もしない) だけの場合は、スタブを使用します。関数が呼び出されたかどうかはあまり気にしません。単に物事を分離したいだけです。

モックはより強力です。関数が呼び出されたかどうか、何回呼び出されたかを追跡でき、関数が取得した値を使用して処理を実行することもできます。

あなたの場合、データベースをモックしたい場合 (機能テストではなく単体テストになるため)、ISession と ITransaction をモックできます。次に、この値をメモリに保存し、正しい値が保存されたかどうかを確認できます。

于 2009-08-17T14:23:29.387 に答える
2

作成したコードをテストする必要があります。データベース接続オブジェクト コードを記述した場合は、それをテストします。それ以外の場合は、独自のテストを含むライブラリの一部である場合は、それをモック/スタブして、接続オブジェクトが独自のテスト スイートに合格した場合に動作すると想定できます。

たとえば、私は Hibernate メソッドの呼び出しをテストしません。Hibernate の開発者はすでに徹底的にテストしていると思います。しかし、モックを使用してその期待値を設定し、正しいメソッドを呼び出していることをテストします。

于 2009-08-17T14:21:09.343 に答える
0

ほとんどの種類の単体テストは、コードの個々の部分をテストすることに関するものであり、スタブとモックは、部分ごとにテストするのに役立つ単なるツールです。ピースを個別にテストすることで、おそらく各ピースをより詳細にテストできますが、全体像については何も保証されません. さまざまな種類の統合テストがそれを行います。

より大きな機能をテストする場合、データベース ロジックの実際の統合テストは最も価値の低いテスト アーティファクトであることがよくあります。これは、これらの同じ操作を UI レベルでテストすることが多いためです。

于 2009-08-17T14:25:37.137 に答える
0

はい、実際のデータベースを使用すると、定義に応じて、より機能的または統合テストになります。個人的には、単体テストは、他のすべてを分離して、そのメソッドのみを正確にテストすることになっていると感じています。したがって、セッションまたはトランザクションが機能するかどうかに関係なく、単体テストでは、必要なときに必要に応じてそれらのオブジェクトが呼び出されて機能することを確認する必要があります。ここで、モックとスタブの出番です。これらを使用して、ユニットがテストは、基本ユニットとしてテストできるように、外部機能から分離されています。とにかく理想的。

于 2009-08-17T14:19:27.067 に答える