ライブラリの関数のモックバージョンをエクスポートすることはベストプラクティスですか、それともアンチパターンですか？
環境
サードパーティにAPI（HTTP）リクエストを送信するライブラリを作成しています。
テスト中に、他の機能を独立してテストできるように、外部リクエストを行う関数のモックバージョンを作成しました。
質問
ライブラリの関数のmockバージョンをエクスポートして、アプリケーションusingがライブラリのモックを使用できるようにする必要があります'モックの重複を避けるための独自のテスト？
例：（pseudocode）
if (ENV=="test") {
return MockImplementation
}
else {
return RealImplementation
}
これは "anti-pattern"または " best-practice "ライブラリ作成時？
注：practiceで何をするかを明確にするために、意見や炎上戦争を探すのではありません。
これをグーグルで試しましたが、関連する結果は表示されませんでした...直接的な質問です。
これがでない場合このタイプの質問をする適切な場所、は？
洞察力は大歓迎です！ありがとう！
追加の詳細
モックライブラリ/フレームワークは使用していません。私たちのモックは単にサンプルの応答を返します。問題のAPI（Google！）には「テスト」エンドポイントがないため、構築中のライブラリを使用するアプリケーションは同じリクエストを模擬する必要があります。私は特定になりすぎないようにしていますので、質問は一般的です。私たちが作成したライブラリは一般的な使用を目的としていますが、using自分のアプリ/プロジェクトでduplicateライブラリのモック。
- モックはseparateライブラリにあると思います。
- あなたのモックはテスターをあなたが選んだ特定のモックフレームワークに結びつけます。
- テスト条件とアサーションを設定する責任があるので、テスターは通常モックを作成する人です。
- 優れたAPIは通常、必要なモックが少なくなります。モックライブラリを作成する努力は、APIの改善に費やされる可能性があります。
- モックは、テストしている特定のソフトウェアと密接に関連しています。
ボトムライン？モックが役立つと思われる場合は、モックを別のライブラリに含めます。しかし、これらのモックはtheirソフトウェアではなくyourライブラリのテストに主に役立ちます。
まず、私は Gerard Meszarosからの定義 を使用しています。
あなたが話しているのは、ライブラリのクライアントがテストを書くときに、実際の実装の代わりにこのdoubleを使用できるように、テストdoubleを提供することです。おそらく作成するものは、モックよりもフェイクに近いものです。つまり、テストdoubleは、特定のモック/テストフレームワークを使用せずに通常のコードとして実装され、高速の分離された自動テストで使用できる実際の実装になります。インメモリデータベースが良い例です。または、あなたのケースでは、おそらくあなたのサービスの単純なインメモリ実装です。
また、これらのテストダブルを別のライブラリとして提供する必要があります。これらのライブラリは、実際のライブラリと同じインターフェイス/抽象化を実装し、DIコンテナーで置き換えるか、実際のインスタンスではなく単にテストインスタンスを渡すだけで簡単に置き換えることができます。
上記があなたがそれをする方法であるなら、私は間違いなくそれをすることを勧めます。ソフトウェアのデバッグ時にオンラインで何もセットアップしたりネットワーク接続を確立したりすることなく、サービスに対してコードの動作をテストする簡単な方法があることは、ライブラリのユーザーにとって素晴らしいサービスです。もちろん、これは、これらのテストdoubleが実際の実装に可能な限り近く動作するように細心の注意を払っていることに依存します。