1) API ラッパーで動作する何かをテストするときは、API ラッパー クラス全体をモックし、エラー状態として例外のスローをシミュレートし、アプリケーション自体がこれらの例外にどのように反応するかをテストする必要があります。
おそらく、API 応答に依存するいくつかの操作を停止し、ユーザー フレンドリーなエラーを表示するはずです。
さらに、API ラッパーのどのメソッドが呼び出されたか、何回、どのパラメーターが渡されたかをテストできます (おそらくそうすべきです)。
<?php
public function testShowUser() {
$fb = $this->getMock( 'Facebook\Api' );
$fb->expects( $this->once() ) // if your library will call getUserInfo() more than once or never, the test will fail
->method( 'getUserInfo' )
->with( $this->equalTo( 'johndoe' ) ) // if the method will be called with different parameter, the test will fail
->will( $this->throwException( 'Facebook\NonExistingUser' ) );
$myApp = new MyApp( $fb );
$myApp->renderUser( 'johndoe' ); // if this will throw uncaught exception, the test will fail
$this->assertEquals(
array( 'The user you requested does not exist' ),
$myApp->getFlashMessages()
);
}
2) API ラッパー自体をテストする場合、APIからの生の応答をモックできます。
HTTP 通信に関するすべてのものを特定のクラス (Curl ラッパー /独自の単体テスト付き) に分離し、サーバーが特定の HTTP コードと応答を返したと想定する必要があります。
可能なすべての種類の応答をファイルに保存できるため、それらを応答としてテストにロードできます。
このようにすることをお勧めします:
<?php
/**
* @expectedException Facebook\NonExistingUser
*/
public function testUnavailableApi() {
$curl = $this->getMock( 'CurlWrapper' );
$curl->expects( $this->once() )
->method( 'getBody' )
->will( $this->returnValue( file_get_contents( 'fb_404_response.json' ) ) );
$curl->expects( $this->once() )
->method( 'getStatusCode' )
->will( $this->returnValue( 404 ) );
$api = new Facebook\Api( $curl );
$api->getUserInfo( 'johndoe' );
}