外部APIの返却値に応じた処理の単体テストの実施方法

Question

現在外部APIが処理途中で入るようなAPIの作成を行っています。
外部APIを処理途中に挟んでいるのですが、その処理結果を用いての単体テストをどう行えばよいのか悩んでいます。

public 作成したAPI(){
　　API内の処理
　　・・・
　　var response = 外部APIを実行するメソッド();
　　
　　try{
　　　　// メソッドのステータスコードを参照し、200以外エラーとする。
　　　　if(response.ステータス == 1){
　　　　　　Exception
　　　　}else if(response.ステータス == 2){
　　　　　　Exception
　　　　｝
　　　　続きの処理
　　　　・・・
　　}catch(Exception e){
　　　エラー処理
　　}
}

「作成したAPI()」の単体テスト実施時に、上記の「外部APIを実行するメソッド()」で返却されるステータスを任意で指定したいのですが
上記のような場合の単体テストの実施方法について、アドバイスや方法が記載されているWEBサイトをご教示いただきたいです。

以下、環境です。
OS：Windows 10
FW：.Net Framework 4.5.2
IDE：Visual Studio 2017

お忙しい中ご参照いただきありがとうございます。
よろしくお願いいたします。

Comments

[Zuishin]

リリース時には外部 API を、テスト時にはモックを呼び出すコードを書き、現在の外部 API を呼び出している部分をそれに差し替えてテストする方法がポピュラーです。

[kusozako...]

Zuishinさん

ご教示ありがとうございます。

具体的なイメージですが、下記のようでよろしかったでしょうか。
「外部APIを実行するメソッド()」の外部APIを実行する箇所で
1. 本番用とテスト用で分岐を作る
2. テスト用として実行時には接続先をモックとし、モックの返却値は実行時のパラメーター等で判断させる。

このような場合テストコードが混ざった状態で本番リリースとなるのがよいのか？というような気がしてるのですが、一般的にそのあたりは許容されているものなのでしょうか？

[Zuishin]

分岐を作るのではなく、依存性注入を行います。

[SurferOnWww]

質問者さん、無言ですが、回答が出ているのでそれらに対するフィードバックをタイムリーに返してください。役に立った/立たなかったぐらいはすぐに返せるのでは？ 役に立たなかったならどこがダメかを書くとより期待に近い回答が出てくるかも。とにかく無言は NG です。

Answer 1

リポジトリパターンを考えてはいかがですか？

以下の画像は ASP.NET MVC でデータベースアクセスを行う場合ですが、質問者さんのケースでも応用は可能だと思います。

出展: ASP.NET MVC 実践プログラミング (秀和システム)

Answer 2

interface IAPI {
  int method();
}

/* 本番ではコレ使う */
class RealAPI : IAPI {
  public int method() { return 0; /* return 外部APIを実行するメソッド(); */ }
}

// テスト対象
class TestTarget {
  IAPI api;
  public void SetAPI(IAPI p) { api = p; }

  public void 作成したAPI() {
    System.Console.WriteLine("{0} が返ってきた", api.method());
  }
}

// テスト用のなんちゃってAPI
class FakeAPI : IAPI {
  public int result;
  public void SetResult(int r) { result = r; }
  public int method() { return result; } // result をそのまま返す
}

class Program {
  static void Main() {
    var target = new TestTarget();

    FakeAPI api = new FakeAPI(); // 本番では RealAPI を使う
    target.SetAPI(api);

    api.SetResult(123);

    target.作成したAPI();
  }
}

Comments

[SurferOnWww]

それは私の回答で書いた「リポジトリパターン」というやつです。（実装はともかく基本的には）

同じ答えを書いてはいけないというルールはないかもしれませんが、あまり褒められたことではないかと。

[episteme]

おっしゃる通りです。
Zuishinさんのおっしゃる「依存性注入」(依存性逆転の原則)というやつです。
さらに言えば デザインパターンのひとつ「Strategy パターン」でもありますね。

[SurferOnWww]

> Zuishinさんのおっしゃる「依存性注入」(依存性逆転の原則)というやつです。

いわゆる DI は私の回答では言及してません。

[episteme]

ですね。DIはリポジトリパターン/Strategyパターンの"実現手段"でしょうから、
説明のレイヤが異なりますか。

[SurferOnWww]

DI の定義によると思います。例えば、DI の定義を「依存するオブジェクトを渡す」ということとすれば、上の私の回答の「リポジトリパターン」には DI を利用できるというだけで、オーバーラップする部分はあるかもしれませんがイコールではありません。

自分が知らないだけで、ひょっとしたら「リポジトリパターン」＝「DI」という話もあるかもしれないということは否定できませんが。

[kusozako...]

ご回答ありがとうございます。
具体的な実装方法も記載いただきましたので、今回ベストアンサーとさせていただきました。
ご教示いただきありがとうございます！