10

Martin Fowler のMocks Aren't Stubsを読んだ後、私は「モック主義者」のやり方で TDD を実践してきたことに気付きました。

しかし、モッキングをやりすぎることができるかどうかは、モッキングTDDでも疑問に思っています。

Python スタイルの疑似コードで更新された例を次に示します。

def sync_path(self):
    if self.confirm_or_create_connection():
        self.sync(self.dirpath)

confirm_or_create_connection() メソッドは、サーバーへの接続を作成します。

これに似たメソッドを 2 つのテストでテストしましたが、どちらも confirm_or_create_connection() と sync() をモックしています (両方とも同じクラスのメソッドですが)。1 つのテストでは、モック confirm_or_create_connection() は True を返し、テストは sync() が呼び出されたことを確認します。別のテストでは、モック confirm_or_create_connection() は False を返し、テストは sync() が呼び出されなかったことを確認します。

これは合理的ですか？または、confirm_or_create_connection() と sync() が呼び出すオブジェクトをモックする必要がありますか? (すでにこれを行っているこれらの方法の両方の他のテストがあります。)

代わりに「古典的な」TDD を実践すべきだと説明して、質問に答えないでください。これは、別の質問に対する答えです。モックストまたは従来の TDD を実践する必要がありますか?

4

7 に答える 7

8

この手法は、理由により「モック メソッド」ではなく「モック オブジェクト」と呼ばれます。これにより、システムを簡単に構成され、共同作業を行うオブジェクトに分割し、手続き型コードから切り離す設計が奨励されます。目的は、抽象化のレベルを上げて、主にオブジェクトを作成してプログラミングし、低レベルの制御フロー ステートメントをほとんど記述しないようにすることです。

于 2009-05-23T16:37:48.950 に答える
5

個人的には、自分自身を嘲笑することは、ほとんどの場合、コードの匂いだと思います。動作ではなく実装をテストしています。

于 2008-10-08T21:07:14.617 に答える
4

更新されたサンプル用に編集:

今わかりました。このクラスには設計上の欠陥があるため、このクラスのテストに問題があります。このクラスは、単一責任の原則に違反しています。それは2つのことをしています。まず、データベースへの接続を管理しています。これも同期です。

データベース接続を管理するには、別のクラスが必要です。このクラスは、テスト対象のクラスの依存関係になります。テスト対象のクラスを単体テストすると、データベース接続クラスを偽造できます。

以前:

仲間の相互作用テスターとして、これを行う必要がある場合はリファクタリングを検討してください。そのクラスはおそらくやりすぎです。

このように説明しましょう: プライベート メソッドを呼び出しても、対話は行われません。

これは TDD の主要なポイントの 1 つです。それが痛いときは、デザインを改善できます。

于 2009-05-15T18:52:32.163 に答える
1

大雑把に推測すると、接続アクティビティが委任されるべき別のオブジェクトに属している可能性があるように見えます。その場合、それをモックできます。通常、オブジェクトの一部をモックして別の部分をテストすることはお勧めしません。これは、2 つの概念が一緒にボルトで固定されていることを示唆しています。

于 2009-05-21T16:48:55.050 に答える
1

新しい例用に編集
私には、confirm_or_create_connection をスタブ化しているように見えます。戻り呼び出しを定義することにのみ関心があり、sync をモックしています。ここでは、実際に呼び出されたかどうかをテストすることに関心があります。（スタブまたはモックの私の定義が、あなたが参照したファウラーの記事と同じかどうかを確認する必要があります。それを読んでからしばらく経ちましたが、C＃でライノモックを使用しており、独自の定義がある可能性がありますこれらの用語:-))

あなたがテストしているものについては、これらの呼び出しをモックしてスタブ化することが正しい方法だと思います。これらの関数の 1 つにエラーがある場合に失敗するようにテストする必要はありません。そのための他のテストがあります。sync_path の動作をテストしたいだけです。

私はこれがちょっと臭いというAvdiに同意します. テストは問題ありませんが、クラスがやりすぎている可能性があります。

于 2008-10-08T20:43:54.430 に答える
0

http://xunitpatterns.com/Principles%20of%20Test%20Automation.html#Donの「原則：SUTを変更しないでください」

実装の一部をモックまたはスタブすることによってテストしているクラスを変更することは、コードの臭いです。それから逃れるためのリファクタリングは、モック/スタブしている部分を別のクラスに移動することです。とはいえ、必ずしもひどいことではありません。そのコードの臭いが、常に不適切であるとは限りません。優れたリファクタリングツールがあるC＃やJavaのような言語の場合、このコードの臭いを簡単に修正できます（C＃では、Javaが類似していると仮定します）。私はLuaとJavascriptで多くの開発を行っていますが、状況は少し異なります。これらの言語で多くのクラスを作成および管理することはより困難であるため、テストでSUTを変更することに対してより寛容です。最初のテストカバレッジがそこにあると、それは常に後で修正できるものです。特別な注意が必要です。

于 2010-02-19T17:46:15.903 に答える
0

あざけることはできますか？あまりにも遠いことはわかりませんが、コードの代わりに実際にモックをテストしている、またはさらに悪いことに、脆弱なテストを行っているなど、ひどく行われる可能性があります。

しかし、良いテスト (期待される動作を確認するテスト、コードの作成に役立つテスト) を作成している限り、モックを作成してください。

于 2008-11-17T00:39:15.047 に答える