テストの観点から、コードには次の 2 つの問題があります。
- URL はハードコーディングされているため、開発、テスト、または本番用に変更する方法はありません
- エンドポイントは、データを取得する方法を知っています。あなたのコードからは、エンドポイントが実際に何をするかはわかりませんが、それが低レベルの「Just get me Data」オブジェクトでない場合、データを取得する方法を知る必要はありません。
このようなコードでは、コードをテストする良い方法はありません。リフレクションを操作したり、コードを変更したりできます。このアプローチの問題は、実際のオブジェクトをテストするのではなく、テストで動作するように変更されたリフレクションをテストすることです。
「良い」テストを書きたい場合、エンドポイントは次のようになります。
class Endpoint {
private $dataParser;
private $endpointUrl;
public function __construct($dataParser, $endpointUrl) {
$this->dataPartser = $dataParser;
$this->endpointUrl = $endpointUrl;
}
public function parseThirdPartyResponse() {
$response = $this->dataPartser->fetchUrl($this->endpointUrl);
// ...
}
}
これで、テストしたいものに応じてデフォルトの応答を返す DataParser のモックを注入できます。
次の質問は次のようなものかもしれません: DataParser をテストするにはどうすればよいですか? ほとんどの場合、そうではありません。PHP 標準関数の単なるラッパーである場合は、その必要はありません。DataParser は、次のように非常に低レベルである必要があります。
class DataParser {
public function fetchUrl($url) {
return file_get_contents($url);
}
}
テストが必要な場合、またはテストしたい場合は、テスト内に存在し、「モック」として機能する Web サービスを作成し、常に事前構成されたデータを返すことができます。次に、実際の URL の代わりにこのモック URL を呼び出して、戻り値を評価できます。
