APIクライアントの単体テストを実際に行う価値はありますか？

これは今しばらく私を悩ませてきたものです。APIクライアントの単体テストを実際に行う価値はありますか？

petshop REST APIへの呼び出しを抽象化するための小さなクラスを作成しているとしましょう。petshopは非常に単純なAPIであり、基本的なメソッドセットがあります。

• listProducts()
• getProductDetails(ProductID)
• addProduct(...)
• removeProduct(ProductID)

これをテストするには、モックサービスを作成するか、応答をモックする必要があります。しかし、それは行き過ぎのようです。タイプミス/構文エラーによってメソッドの動作が停止しないことを確認したいのですが、リモートメソッドを呼び出す関数を作成し、それらのリモートメソッドから偽の応答を作成しているため、努力の無駄であり、実際に失敗することのない何かをテストしています。さらに悪いことに、リモートメソッドが変更された場合、本番環境の使用が失敗している間にユニットテストに合格します。

何かが足りないのか、スティックの端が間違っているのか、木の代わりに木が見えないのはかなり確かです。誰かが私を正しい軌道に乗せることができますか？

リモートAPIクライアントの仕事は、特定の呼び出しを発行することです-これ以上でもそれ以下でもありません。したがって、テストでは、これらの呼び出しを発行することを検証する必要があります-これ以上でもそれ以下でもありません。

もちろん、APIプロバイダーが応答のセマンティクスを変更すると、システムは実稼働で失敗します。しかし、それはクライアントクラスのせいではありません。それは統合テストでしか捕まえられないものです。あなたの制御下にないコードに依存することにより、内部テストを介して正確性を検証する機能を放棄しました。これはトレードオフであり、これが価格です。

ただし、別のクラスへの委任のみで構成されるクラスのテストは、複雑なエラーのリスクが比較的少ないため、優先順位が低い場合があります。しかし、それは均一なワンライナーのみで構成されるクラスに当てはまり、別のベンダーのコードを呼び出すこととは関係ありません。

短い答え：

すべてのメソッドは単体テストする必要があります。

長い答え：

はい。それは価値があります。

これらは、API呼び出しメソッドの単体テストでテストする必要があるものです。

• 整形式または正しいパラメーターをAPI呼び出しに渡していること。
• たとえば、APIが空の文字列を返す場合、メソッドがデフォルト値を返す必要がある場合（例）
• API呼び出しでエラーが発生したときに呼び出し元のメソッドが正しく動作すること

これらは、呼び出されたメソッドが行うことであり、APIサービスをモックすることで分離でき、APIを呼び出すクライアントコードのエラーによってエラーが発生しないことを保証します。

これらは、制限された統合テストのように、システムの入出力をテストしているため、単体テストではありません。

「努力の無駄のようであり、実際に失敗しないものをテストしている」と言うときは非常に注意してください-それは失敗する可能性があり、失敗します、おそらくあなたが予想できない方法で失敗します、テストを実施していない場合、失敗はさらに悪化します。

ここであなたが犯している間違いは、車輪の発明に関係しています：リモートサービスとAPIへの呼び出しは非常に一般的なシナリオであるため、テストに役立ついくつかの非常に優れたツールがあります。前回、リモートサービスに接続するアプリケーションで作業していたときに、SoapUIを使用しましたサービスを見て、そのサービスに対して模擬呼び出しを行うか、サーバーのローカルコピーとして動作することができます。サーバーのテストコールを行い、要求と応答を追跡できます。セットアップには数分かかり、リモートインターフェイスが変更された場合も同様に非常に迅速に更新できました。私はRESTシナリオでは使用していませんが、それがうまく機能しない場合（またはおそらくより良いツールが存在するときに誰かがこの答えを読んでいる場合）でも、モックアップできるツールを見つけることができるはずですあなたのためのサービスであり、コードを展開するときが来たら、あなたはあなたがしたことをうれしく思います。