サードパーティのライブラリにインターフェイスを実装する戦略？

Question

いくつかのクラスの単体テストを書きたいと思います。私のクラスの中には、ファイルシステムを使用し、模擬するインターフェースを持たない第三者のライブラリに依存するものがあります。

私のコードは実際にはそのコードの結果だけに関係しているので、私はファイルシステムへの依存関係を避けるためにクラスを嘲笑したいと思います。

初期ライブラリを変更せずに、ライブラリの具体的なクラスを模擬するのに最適な方法は何ですか？

私はインターフェイスを実装し、初期ライブラリのオブジェクトを含むラッパーオブジェクトを作成するかもしれないと思っています。しかし、私はこの道を始める前に、より良い方法がないか確かめたいと思っています。

また、この場合、TypeMockのようなツールはMoqよりも適していますか？

Answer 1

背景：

それは.NETフレームワークのような安定したライブラリ/フレームワークのない限り、私はそれから私のコードを分離することを好みます。つまり、私は図書館が私のシステムに依存するのではなく、そのシステムに依存するようにしたい。

編集、再編集：「安定した」ライブラリを使用していると考えられます。しかし、それは "外部"システム（ファイルシステム）とやりとりするので、私はおそらくそれから私のシステムを切り離したいと思うでしょう。

これを達成するために、ライブラリのアダプタ/ラッパーを作成します。インタフェースには、私のシステムがライブラリに持たせたいメソッドがあり、ライブラリが提供するメソッドはありません。インタフェースは私のシステムが所有する型を使用し、ライブラリの型は使用しません。アダプターは必要な変換を行います。

これは、私がライブラリを模擬/スタブ/偽装したいかどうかにかかわらず、心配の良い分離を提供し、ライブラリの変更からシステムを保護するためです。あなたの質問へ

回答：

アダプタ/ラッパーがあったら、それはそれあなたのテストで偽に簡単です。アダプターはシステムの言語を使用するため、読みやすく理解しやすいテストを書くのが簡単になります。

擬似フレームワークを使用するのか、アダプテーターのための独自の偽物を書くのかは、味わいの問題です。