3

まず、質問の理由 - 公式の pymox ドキュメント: https://code.google.com/p/pymox/wiki/MoxDocumentation

MockAnythingセクションには、 「絶対に必要でない限り、これを使用しないでください!」という記述があります。. 面白いです どうしてですか？制限はありますか？個人的にはとても重宝しました。

次のような状況があります。クラスにモジュールへの参照があり、モジュールには、クラスで使用されるモジュールレベルの関数がたくさんあります。

import db

class A(object):
    def __init__(self):
        # To make possible dependency injection.
        self.db = db
    ...

class Test_A(object):
    def test(self):
        a = A()
        # Perform an injection.
        a.db = mox.CreateMockAnything()
        # Setting an expectation to any function
        a.db.some_func().AndReturn(5)
        ...

これはモジュールなので、型ではないため、 CreateMock()でモックできません。したがって、この場合に最適なCreateMockAnything()を使用しました。モジュール関数を次のようにスタブできることはわかっています。

self.mox.StubOutWithMock(module_to_mock, 'FunctionToMock') 
module_to_mock.FunctionToMock().AndReturn(foo)

しかし、ここでは毎回 2 つのアクションを実行する必要があるため、この方法は好きではありません。クラス内のモジュールへの参照を持ち、それをCreateMockAnythingでモックする方が簡単できれいです。

関数名を誤って印刷すると、期待は失敗するだけなので (テストされているコードが正しいものを呼び出しているため)、これはポイントではありません...

StubOutWithMock の場合: テストされたメソッドで追加の db 関数呼び出しに気付かず、StubOutWithMockをスタブしない場合、実際のコードが呼び出され、db にゴミが残ります。したがって、ソリューションを保護するためのもう 1 つのポイント -特定のメソッドをスタブ化する代わりにCreateMockAnythingを使用すると、データベースへの依存関係を完全にカットできます。また、MockAnything モックによってスローされる予期しないメソッド呼び出しの例外も表示されます。

では、 CreateMockAnything()の使用を避ける理由は何ですか?

ありがとう、

4

1 に答える 1

0

これの主な理由は、可能であれば、適切に定義されたインターフェイスを持つオブジェクトのみを使用することが、通常は適切なプログラミング手法であるためです。

あなたのケースで私が見ることができることから、それは完全に受け入れられるユースケースです.

于 2015-07-17T12:14:47.293 に答える