APIクライアントとラッパーのユニットテスト
私は、開発中のAPIクライアントライブラリを単体テストするための最良の方法を見つけようとして、一周して回りました。このライブラリには、Client基本的にAPIとの1：1マッピングを持つWrapperクラスと、の上部でよりユーザーフレンドリーなインターフェイスを提供する追加のクラスがありますClient。 Wrapper --> Client --> External API 私は最初の両方に対してテストの束を書いたClientし、Wrapper効果的にちょうど彼らが前方（上で動作するものは何でもの適切な機能にそのことをテストし、Wrapper上の動作Client、およびClientHTTP接続で動作します）。しかし、インターフェイスではなくこれらのクラスの実装をテストしているように感じるので、これに不快感を覚え始めました。理論的には、クラスを別の完全に有効な実装に変更することはできましたが、呼び出されると予想されていた関数が呼び出されていないため、テストは失敗します。それは私にとって脆弱なテストのように聞こえます。 この後、クラスのインターフェースについて考えました。テストでは、クラスが実際に行う方法ではなく、クラスが実際に意図したジョブを実行することを確認する必要があります。どうすればこれを行うことができますか？最初に頭に浮かぶのは、外部APIリクエストをスタブ化することです。しかし、私は外部サービスを単純化しすぎることに神経質です。私が見たスタブAPIの例の多くは、定型応答を提供しているだけです。これは、コードが偽のAPIに対して正しく実行されることをテストするだけの非常に簡単な方法のようです。別の方法はサービスをモックすることです。これは実行不可能であり、実際のサービスが変更されるたびに最新の状態に維持する必要があります。 最後に、私はこれを に、プログラマーSEに関する別の回答ました。 リモートAPIクライアントの仕事は、特定の呼び出しを発行することです-これ以上でもそれ以下でもありません。したがって、そのテストでは、これらの呼び出しを発行することを確認する必要があります-これ以上でもそれ以下でもありません。 そして今、私は多かれ少なかれ確信しています-テストするとき、テストClientする必要があるのは、APIへの正しいリクエストを行うことだけです（もちろん、APIが変更される可能性は常にありますが、私のテストは合格し続けます-しかしそれは統合テストが役立つ場合）。以来Clientちょうど1：APIと1のマッピング、私の懸念は実際には適用されません別の有効な実装から変更について前に-の各メソッドの唯一の有効な実装がありますClient。 しかし、私はまだにこだわっています Wrapperクラスにます。次のオプションが表示されます。 Clientクラスをスタブ化し、適切なメソッドが呼び出されることをテストします。このように、私は上記と同じClientことをしていますが、APIの代用として扱います。これは私が始めたところに私をすぐに戻します。繰り返しになりますが、これはインターフェースではなく実装のテストの不快感を与えてくれます。のWrapper非常によく、完全に別のクライアントを使用して実施することができます。 モックを作成しますClient。ここで、モックを作成する方法を決定する必要があります。サービスの完全なモックを作成するには、多くの労力が必要になります（ライブラリ自体に行った以上の作業）。API自体はシンプルですが、サービスは非常に複雑です（基本的に、そのデータに対する操作を備えたデータストアです）。そして再び、私は私のモックを本物と同期させておく必要がありますClientます。 適切なHTTPリクエストが行われていることをテストするだけです。これはWrapper、実際のClientそれらのHTTP要求を行うためにオブジェクトをため、実際に個別にテストするわけではありません。これは少しひどい単体テストになります。 したがって、これらのソリューションのいずれにも特に満足していません。あなたならどうしますか？これについて正しい方法はありますか？