unittest.mock —はじめに—Pythonドキュメント
unittest.mock —はじめに
バージョン3.3の新機能。
モックの使用
模擬パッチ適用方法
Mock オブジェクトの一般的な使用法は次のとおりです。
- パッチ適用方法
- オブジェクトに対するメソッド呼び出しの記録
オブジェクトのメソッドを置き換えて、システムの別の部分によって正しい引数で呼び出されていることを確認することをお勧めします。
モックが使用されると(この例ではreal.method
)、モックがどのように使用されたかについてアサーションを作成できるメソッドと属性があります。
モックが呼び出されると、その呼び出された属性はTrue
に設定されます。 さらに重要なことに、 assert_called_with()または assert_called_once_with()メソッドを使用して、正しい引数で呼び出されたことを確認できます。
この例では、ProductionClass().method
を呼び出すと、something
メソッドが呼び出されることをテストします。
オブジェクトのメソッド呼び出しのモック
最後の例では、オブジェクトに直接メソッドをパッチして、正しく呼び出されたことを確認しました。 もう1つの一般的な使用例は、オブジェクトをメソッド(またはテスト対象のシステムの一部)に渡し、それが正しい方法で使用されていることを確認することです。
以下の単純なProductionClass
には、closer
メソッドがあります。 オブジェクトで呼び出されると、close
が呼び出されます。
したがって、テストするには、close
メソッドを使用してオブジェクトを渡し、正しく呼び出されたことを確認する必要があります。
モックに「close」メソッドを提供するために、何もする必要はありません。 closeにアクセスすると作成されます。 したがって、「close」がまだ呼び出されていない場合、テストでそれにアクセスすると作成されますが、 assert_called_with()は失敗例外を発生させます。
モッククラス
一般的なユースケースは、テスト対象のコードによってインスタンス化されたクラスをモックアウトすることです。 クラスにパッチを適用すると、そのクラスはモックに置き換えられます。 インスタンスは、クラスを呼び出すことによって作成されます。 これは、モックされたクラスの戻り値を見て、「モックインスタンス」にアクセスすることを意味します。
以下の例では、Foo
をインスタンス化してそのメソッドを呼び出す関数some_function
があります。 patch()を呼び出すと、クラスFoo
がモックに置き換えられます。 Foo
インスタンスはモックを呼び出した結果であるため、モック return_value を変更して構成されます。
モックに名前を付ける
モックに名前を付けると便利です。 名前はモックのreprに表示され、モックがテスト失敗メッセージに表示されるときに役立ちます。 名前は、モックの属性またはメソッドにも伝達されます。
すべての通話を追跡する
多くの場合、メソッドへの複数の呼び出しを追跡する必要があります。 mock_calls 属性は、モックの子属性へのすべての呼び出しと、その子へのすべての呼び出しを記録します。
mock_calls
についてアサーションを作成し、予期しないメソッドが呼び出された場合、アサーションは失敗します。 これは、予期した呼び出しが行われたことを表明するだけでなく、それらが正しい順序で行われ、追加の呼び出しがないことも確認しているため、便利です。
call オブジェクトを使用して、mock_calls
と比較するためのリストを作成します。
ただし、モックを返す呼び出しのパラメーターは記録されません。つまり、祖先の作成に使用されるパラメーターが重要なネストされた呼び出しを追跡することはできません。
戻り値と属性の設定
モックオブジェクトに戻り値を設定するのは簡単です。
もちろん、モックのメソッドについても同じことができます。
戻り値はコンストラクターでも設定できます。
モックに属性設定が必要な場合は、次のようにします。
mock.connection.cursor().execute("SELECT 1")
など、より複雑な状況をモックアップしたい場合があります。 この呼び出しでリストを返すようにする場合は、ネストされた呼び出しの結果を構成する必要があります。
call を使用して、後で簡単にアサーションできるように、次のような「連鎖呼び出し」で一連の呼び出しを作成できます。
呼び出しオブジェクトを連鎖呼び出しを表す呼び出しのリストに変換するのは、.call_list()
への呼び出しです。
副作用関数と反復可能
side_effect
は関数または反復可能に設定することもできます。 反復可能としてのside_effect
のユースケースは、モックが数回呼び出され、各呼び出しが異なる値を返すようにする場合です。 side_effect
をイテラブルに設定すると、モックを呼び出すたびにイテラブルから次の値が返されます。
モックが何で呼び出されるかに応じて戻り値を動的に変化させるなど、より高度なユースケースでは、side_effect
を関数にすることができます。 関数は、モックと同じ引数で呼び出されます。 関数が返すものはすべて、呼び出しが返すものです。
非同期イテレータのモック
Python 3.8以降、AsyncMock
およびMagicMock
は、非同期イテレーターから__aiter__
のモックをサポートしています。 __aiter__
の return_value 属性を使用して、反復に使用する戻り値を設定できます。
非同期コンテキストマネージャーのモック
Python 3.8以降、AsyncMock
およびMagicMock
は、非同期コンテキストマネージャーから__aenter__
および__aexit__
のモックをサポートしています。 デフォルトでは、__aenter__
と__aexit__
は非同期関数を返すAsyncMock
インスタンスです。
既存のオブジェクトからモックを作成する
モックの使いすぎに関する問題の1つは、テストが実際のコードではなくモックの実装に結合されることです。 some_method
を実装するクラスがあるとします。 別のクラスのテストでは、もがsome_method
を提供するこのオブジェクトのモックを提供します。 後で最初のクラスをリファクタリングして、some_method
がなくなると、コードが壊れていても、テストは引き続き合格になります。
Mock では、 spec キーワード引数を使用して、モックの仕様としてオブジェクトを提供できます。 仕様オブジェクトに存在しないモックのメソッド/属性にアクセスすると、すぐに属性エラーが発生します。 仕様の実装を変更すると、そのクラスを使用するテストは、それらのテストでクラスをインスタンス化する必要なしに、すぐに失敗し始めます。
仕様を使用すると、一部のパラメーターが定位置引数または名前付き引数として渡されたかどうかに関係なく、モックに対して行われた呼び出しのよりスマートなマッチングも可能になります。
このよりスマートなマッチングをモックのメソッド呼び出しでも機能させたい場合は、自動仕様を使用できます。
任意の属性の設定と取得を防ぐ、より強力な仕様が必要な場合は、 spec の代わりに spec_set を使用できます。
パッチデコレータ
テストでよく必要なのは、クラス属性またはモジュール属性にパッチを適用することです。たとえば、組み込みのパッチを適用したり、モジュール内のクラスにパッチを適用して、インスタンス化されていることをテストしたりします。 モジュールとクラスは事実上グローバルであるため、テスト後にパッチを適用する必要があります。そうしないと、パッチが他のテストに残り、問題の診断が困難になります。
モックは、 patch()、 patch.object()、 patch.dict()の3つの便利なデコレータを提供します。 patch
は、package.module.Class.attribute
の形式の単一の文字列を取り、パッチを適用する属性を指定します。 また、オプションで、属性(またはクラスなど)を置き換える値を取ります。 'patch.object'は、パッチを適用するオブジェクトと属性の名前に加えて、オプションでパッチを適用する値を取ります。
patch.object
:
モジュール( builtins を含む)にパッチを適用する場合は、 patch.object()の代わりに patch()を使用してください。
モジュール名は、必要に応じてpackage.module
の形式で「ドット」にすることができます。
良いパターンは、実際にテストメソッド自体を装飾することです。
モックでパッチを適用する場合は、 patch()を1つの引数のみで(または patch.object()を2つの引数で)使用できます。 モックが作成され、テスト関数/メソッドに渡されます。
このパターンを使用して、複数のパッチデコレータを積み重ねることができます。
パッチデコレータをネストすると、モックは適用されたのと同じ順序でデコレートされた関数に渡されます(デコレータが適用される通常の Python の順序)。 これは下から上を意味するため、上記の例では、test_module.ClassName2
のモックが最初に渡されます。
スコープ中にディクショナリに値を設定し、テストの終了時にディクショナリを元の状態に復元するための patch.dict()もあります。
patch
、patch.object
、patch.dict
はすべてコンテキストマネージャーとして使用できます。
patch()を使用してモックを作成する場合、withステートメントの「as」形式を使用してモックへの参照を取得できます。
別の方法として、patch
、patch.object
およびpatch.dict
をクラスデコレータとして使用できます。 このように使用すると、名前が「test」で始まるすべてのメソッドにデコレータを個別に適用するのと同じです。
さらなる例
少し高度なシナリオの例をいくつか示します。
連鎖呼び出しのモック
return_value 属性を理解すれば、連鎖呼び出しのモックは実際にはモックで簡単です。 モックが初めて呼び出されたとき、または呼び出される前にreturn_value
をフェッチすると、新しいモックが作成されます。
これは、return_value
モックに問い合わせることで、モックオブジェクトの呼び出しから返されたオブジェクトがどのように使用されたかを確認できることを意味します。
ここからは、連鎖呼び出しについて構成してアサーションを作成する簡単な手順です。 もちろん、別の方法は、そもそもよりテスト可能な方法でコードを書くことです…
したがって、次のようなコードがあるとします。
BackendProvider
がすでに十分にテストされていると仮定すると、method()
をどのようにテストしますか? 具体的には、コードセクション# more code
が応答オブジェクトを正しい方法で使用することをテストする必要があります。
この一連の呼び出しはインスタンス属性から行われるため、Something
インスタンスのbackend
属性にモンキーパッチを適用できます。 この特定のケースでは、start_call
への最後の呼び出しからの戻り値にのみ関心があるため、実行する構成はあまりありません。 返されるオブジェクトが「ファイルのような」ものであると仮定して、応答オブジェクトが組み込みの open()をspec
として使用するようにします。
これを行うには、モックバックエンドとしてモックインスタンスを作成し、そのモック応答オブジェクトを作成します。 その最終的なstart_call
の戻り値として応答を設定するには、次のようにします。
configure_mock()メソッドを使用して、少し良い方法でこれを実行し、戻り値を直接設定できます。
これらを使用して、「モックバックエンド」にモンキーパッチを適用し、実際の呼び出しを行うことができます。
mock_calls を使用すると、単一のアサートで連鎖呼び出しを確認できます。 連鎖呼び出しは、1行のコードに複数の呼び出しがあるため、mock_calls
には複数のエントリがあります。 call.call_list()を使用して、次の呼び出しリストを作成できます。
部分的なモック
一部のテストでは、 datetime.date.today()の呼び出しをモックアウトして既知の日付を返したいと思っていましたが、テスト対象のコードが新しい日付オブジェクトを作成するのを防ぎたくありませんでした。 残念ながら、 datetime.date はCで記述されているため、静的なdate.today()
メソッドにモンキーパッチを適用することはできませんでした。
日付クラスをモックで効果的にラップすることを含む、これを行う簡単な方法を見つけましたが、コンストラクターへの呼び出しを実際のクラスに渡します(そして実際のインスタンスを返します)。
ここでは、パッチデコレータを使用して、テスト対象のモジュールのdate
クラスをモックアウトします。 次に、モック日付クラスのside_effect
属性が、実際の日付を返すラムダ関数に設定されます。 モック日付クラスが呼び出されると、実際の日付が作成され、side_effect
によって返されます。
datetime.date にグローバルにパッチを適用するのではなく、がを使用するモジュールのdate
にパッチを適用することに注意してください。 パッチを適用する場所を参照してください。
date.today()
が呼び出されると、既知の日付が返されますが、date(...)
コンストラクターを呼び出すと通常の日付が返されます。 これがないと、テスト対象のコードとまったく同じアルゴリズムを使用して期待される結果を計算する必要があります。これは、古典的なテストのアンチパターンです。
日付コンストラクターへの呼び出しは、mock_date
属性(call_count
およびその仲間)に記録されます。これは、テストにも役立つ場合があります。
モック日付やその他の組み込みクラスを処理する別の方法については、このブログエントリで説明されています。
ジェネレータメソッドのモック
Pythonジェネレーターは、 yield ステートメントを使用して、 1 を繰り返したときに一連の値を返す関数またはメソッドです。
ジェネレータオブジェクトを返すために、ジェネレータメソッド/関数が呼び出されます。 その後、繰り返されるのはジェネレータオブジェクトです。 反復のプロトコルメソッドは __ iter __()であるため、 MagicMock を使用してこれをモックできます。
ジェネレーターとして実装された「iter」メソッドを持つクラスの例を次に示します。
このクラス、特にその「iter」メソッドをどのようにモックしますか?
反復から返される値を構成するには( list の呼び出しで暗黙的に)、foo.iter()
の呼び出しによって返されるオブジェクトを構成する必要があります。
- 1
- ジェネレータ式やジェネレータの高度な使用法もありますが、ここではそれらについては気にしません。 ジェネレーターの非常に優れた入門書とその強力さ:システムプログラマーのためのジェネレータートリック。
すべてのテスト方法に同じパッチを適用する
複数のテストメソッドに複数のパッチを配置する場合、明らかな方法は、パッチデコレータをすべてのメソッドに適用することです。 これは不必要な繰り返しのように感じることがあります。 Python 2.6以降では、 patch()(さまざまな形式すべて)をクラスデコレータとして使用できます。 これにより、クラスのすべてのテストメソッドにパッチが適用されます。 テストメソッドは、名前がtest
で始まるメソッドによって識別されます。
パッチを管理する別の方法は、パッチメソッドを使用することです:startおよびstop 。 これらを使用すると、パッチをsetUp
およびtearDown
メソッドに移動できます。
この手法を使用する場合は、stop
を呼び出して、パッチ適用が「取り消されている」ことを確認する必要があります。 setUpで例外が発生した場合、tearDownは呼び出されないため、これは想像以上に厄介な場合があります。 unittest.TestCase.addCleanup()を使用すると、これが簡単になります。
アンバウンドメソッドのモック
今日テストを書いている間、私はアンバウンドメソッドにパッチを当てる必要がありました(インスタンスではなくクラスにメソッドをパッチします)。 どのオブジェクトがこの特定のメソッドを呼び出しているかについてアサートしたいので、最初の引数としてselfを渡す必要がありました。 問題は、これに対してモックでパッチを適用できないことです。これは、バインドされていないメソッドをモックに置き換えると、インスタンスからフェッチされたときにバインドされたメソッドにならないため、セルフパスされないためです。 回避策は、代わりに実際の関数で非バインドメソッドにパッチを適用することです。 patch()デコレータを使用すると、モックを使用してメソッドにパッチを適用するのが非常に簡単になるため、実際の関数を作成する必要があります。
autospec=True
をパッチに渡すと、 real 関数オブジェクトを使用してパッチが適用されます。 この関数オブジェクトは、置き換えるものと同じ署名を持っていますが、内部のモックに委任します。 以前とまったく同じ方法で、モックが自動作成されます。 ただし、これを使用してクラスのバインドされていないメソッドにパッチを適用すると、モックされた関数がインスタンスからフェッチされた場合にバインドされたメソッドに変換されます。 self
が最初の引数として渡されます。これは、まさに私が望んでいたことです。
autospec=True
を使用しない場合、バインドされていないメソッドは代わりにMockインスタンスでパッチが適用され、self
では呼び出されません。
モックで複数の通話をチェックする
モックには、モックオブジェクトの使用方法に関するアサーションを作成するための優れたAPIがあります。
モックが一度だけ呼び出される場合は、assert_called_once_with()
メソッドを使用できます。このメソッドは、call_count
が1つであることも表明します。
assert_called_with
とassert_called_once_with
はどちらも、最新の呼び出しについてアサーションを作成します。 モックが複数回呼び出され、すべてのについてアサーションを作成する場合は、 call_args_list を使用できます。
call ヘルパーを使用すると、これらの呼び出しに関するアサーションを簡単に作成できます。 予想される呼び出しのリストを作成して、call_args_list
と比較できます。 これは、call_args_list
のreprと非常によく似ています。
可変引数への対処
別の状況はまれですが、あなたを噛む可能性があります。それは、モックが可変引数で呼び出される場合です。 call_args
およびcall_args_list
は、引数への参照を格納します。 テスト対象のコードによって引数が変更された場合、モックが呼び出されたときの値についてアサーションを作成できなくなります。
問題を示すサンプルコードを次に示します。 'mymodule'で定義されている次の関数を想像してみてください。
grob
がfrob
を正しい引数で呼び出すことをテストしようとすると、何が起こるかを見てください。
1つの可能性は、モックが渡した引数をコピーすることです。 同等性をオブジェクトIDに依存するアサーションを実行すると、問題が発生する可能性があります。
side_effect
機能を使用する1つのソリューションを次に示します。 モックにside_effect
関数を指定すると、side_effect
がモックと同じ引数で呼び出されます。 これにより、引数をコピーして、後のアサーションのために保存する機会が得られます。 この例では、 another モックを使用して引数を格納しているため、モックメソッドを使用してアサーションを実行できます。 ここでも、ヘルパー関数がこれを設定します。
copy_call_args
は、呼び出されるモックで呼び出されます。 アサーションを実行する新しいモックを返します。 side_effect
関数は引数のコピーを作成し、そのコピーを使用してnew_mock
を呼び出します。
ノート
モックが一度だけ使用される場合は、呼び出された時点で引数をチェックする簡単な方法があります。 side_effect
関数内で簡単にチェックできます。
別のアプローチは、引数をコピーする Mock または MagicMock のサブクラスを作成することです( copy.deepcopy()を使用)。 実装例は次のとおりです。
Mock
またはMagicMock
をサブクラス化すると、動的に作成されたすべての属性がreturn_value
によって自動的に使用されます。 つまり、CopyingMock
のすべての子のタイプもCopyingMock
になります。
ネストパッチ
パッチをコンテキストマネージャーとして使用するのは良いことですが、複数のパッチを実行すると、ステートメントがさらに右にインデントされてネストされる可能性があります。
unittest cleanup
関数とパッチメソッド:startとstop を使用すると、ネストされたインデントなしで同じ効果を実現できます。 単純なヘルパーメソッドcreate_patch
は、パッチを配置し、作成されたモックを返します。
MagicMockで辞書をモックする
辞書やその他のコンテナオブジェクトをモックして、辞書のように動作させながら、そのオブジェクトへのすべてのアクセスを記録することをお勧めします。
これは、辞書のように動作する MagicMock を使用し、 side_effect を使用して、制御下にある実際の基礎となる辞書への辞書アクセスを委任することで実行できます。
MagicMock
の__getitem__()
および__setitem__()
メソッドが呼び出されると(通常の辞書アクセス)、side_effect
がキーを使用して呼び出されます([ X154X] 値も)。 何が返されるかを制御することもできます。
MagicMock
が使用された後、 call_args_list のような属性を使用して、辞書がどのように使用されたかについてアサートできます。
ノート
MagicMock
を使用する代わりに、Mock
を使用し、のみを使用して、特に必要な魔法のメソッドを提供します。
3番目のオプションは、MagicMock
を使用しますが、dict
を spec (または spec_set )引数として渡すことで、作成されたMagicMock
には、辞書の魔法の方法しかありません。
これらの副作用機能を設定すると、mock
は通常の辞書のように動作しますが、アクセスを記録します。 存在しないキーにアクセスしようとすると、 KeyError も発生します。
使用後は、通常のモックメソッドと属性を使用してアクセスに関するアサーションを作成できます。
モックサブクラスとその属性
モックをサブクラス化する理由はさまざまです。 1つの理由は、ヘルパーメソッドを追加することかもしれません。 これはばかげた例です:
Mock
インスタンスの標準的な動作では、属性と戻り値のモックは、アクセスされるモックと同じタイプです。 これにより、Mock
属性がMocks
になり、MagicMock
属性がMagicMocks
2 になります。 したがって、ヘルパーメソッドを追加するためにサブクラス化する場合は、サブクラスのインスタンスの属性と戻り値のモックでも使用できます。
時々これは不便です。 たとえば、 1人のユーザーがモックをサブクラス化してツイストアダプターを作成しています。 これを属性にも適用すると、実際にはエラーが発生します。
Mock
(すべてのフレーバー)は、_get_child_mock
と呼ばれるメソッドを使用して、属性と戻り値のこれらの「サブモック」を作成します。 このメソッドをオーバーライドすることで、サブクラスが属性に使用されるのを防ぐことができます。 署名は、任意のキーワード引数(**kwargs
)を取り、それがモックコンストラクターに渡されることです。
- 2
- このルールの例外は、呼び出し不可能なモックです。 それ以外の場合、呼び出し不可能なモックは呼び出し可能なメソッドを持つことができないため、属性は呼び出し可能なバリアントを使用します。
patch.dictでインポートをモックする
モックが難しい状況の1つは、関数内にローカルインポートがある場合です。 これらは、パッチを適用できるモジュール名前空間のオブジェクトを使用していないため、モックするのが困難です。
一般的に、現地からの輸入は避けなければなりません。 循環依存を防ぐために行われることもありますが、通常は、問題を解決する(コードをリファクタリングする)、またはインポートを遅らせることで「初期費用」を防ぐためのはるかに優れた方法です。 これは、無条件のローカルインポートよりも優れた方法で解決することもできます(モジュールをクラスまたはモジュール属性として保存し、最初の使用時にのみインポートを実行します)。
それはさておき、mock
を使用してインポートの結果に影響を与える方法があります。 インポートすると、 sys.modules ディクショナリからオブジェクトがフェッチされます。 モジュールである必要のないオブジェクトをフェッチすることに注意してください。 モジュールを初めてインポートすると、モジュールオブジェクトが sys.modules に配置されるため、通常、何かをインポートすると、モジュールが返されます。 ただし、これが当てはまる必要はありません。
これは、 patch.dict()を使用して一時的にモックを sys.modules に配置できることを意味します。 このパッチがアクティブな間にインポートすると、モックがフェッチされます。 パッチが完了すると(装飾された関数が終了するか、withステートメントの本体が完了するか、patcher.stop()
が呼び出されます)、以前にあったものはすべて安全に復元されます。
これは、「fooble」モジュールをモックアウトする例です。
ご覧のとおり、import fooble
は成功しますが、終了時に sys.modules に「愚か者」が残っていません。
これは、from module import name
フォームでも機能します。
少し作業が増えると、パッケージのインポートをモックすることもできます。
呼び出しの順序の追跡と冗長性の低い呼び出しアサーション
Mock クラスを使用すると、 method_calls 属性を使用して、モックオブジェクトに対するメソッド呼び出しの order を追跡できます。 これでは、別々のモックオブジェクト間の呼び出しの順序を追跡することはできませんが、 mock_calls を使用して同じ効果を得ることができます。
モックはmock_calls
で子モックへの呼び出しを追跡し、モックの任意の属性にアクセスすると子モックが作成されるため、親モックとは別のモックを作成できます。 これらの子モックへの通話はすべて、親のmock_calls
に順番に記録されます。
次に、マネージャーモックのmock_calls
属性と比較することにより、順序を含む呼び出しについてアサートできます。
patch
がモックを作成して配置している場合は、 attach_mock()メソッドを使用してモックをマネージャーモックにアタッチできます。 通話を添付した後、マネージャーのmock_calls
に記録されます。
多くの呼び出しが行われたが、それらの特定のシーケンスにのみ関心がある場合は、 assert_has_calls()メソッドを使用することもできます。 これは、呼び出しのリストを取ります( call オブジェクトで作成されます)。 その一連の呼び出しが mock_calls にある場合、アサートは成功します。
連鎖呼び出しm.one().two().three()
だけがモックに対して行われた呼び出しではありませんが、アサートは引き続き成功します。
モックに複数の呼び出しが行われる場合があり、それらの呼び出しの一部についてのみ主張することに関心があります。 あなたも注文を気にしないかもしれません。 この場合、any_order=True
をassert_has_calls
に渡すことができます。
より複雑な引数マッチング
ANY と同じ基本概念を使用して、モックへの引数として使用されるオブジェクトに対してより複雑なアサーションを実行するマッチャーを実装できます。
あるオブジェクトがモックに渡され、デフォルトでオブジェクトID(ユーザー定義クラスのPythonのデフォルト)に基づいて等しいと比較されると想定します。 assert_called_with()を使用するには、まったく同じオブジェクトを渡す必要があります。 このオブジェクトの一部の属性のみに関心がある場合は、これらの属性をチェックするマッチャーを作成できます。
この例では、assert_called_with
への「標準」呼び出しでは不十分であることがわかります。
Foo
クラスの比較関数は次のようになります。
また、等式操作にこのような比較関数を使用できるマッチャーオブジェクトは、次のようになります。
これらすべてをまとめると:
Matcher
は、比較関数と比較するFoo
オブジェクトを使用してインスタンス化されます。 assert_called_with
では、Matcher
等式メソッドが呼び出されます。このメソッドは、モックが呼び出されたオブジェクトを、マッチャーを作成したオブジェクトと比較します。 それらが一致する場合、assert_called_with
は合格し、一致しない場合、 AssertionError が発生します。
少し調整するだけで、比較関数で AssertionError を直接発生させ、より有用な失敗メッセージを提供することができます。
バージョン1.5以降、Pythonテストライブラリ PyHamcrest は、同等のマッチャー( hamcrest.library.integration.match_equality )の形式で、ここで役立つ可能性のある同様の機能を提供します。