導入

Zend_Test_PHPUnit(日本語)

Zend_Test_PHPUnitMVC アプリケーション向けのテストケースを用意します。 さまざまな責務に対応したテスト用のアサーションが含まれています。 実際に何ができるのかを知るには、 サンプルを見ていただくのが一番でしょう。

Example #1 Application Login TestCase のサンプル

以下に示すのは UserController 用のシンプルなテストケースで、以下のような内容を検証します。

  • ログインフォームは、未認証のユーザに対しても表示されること。

  • ユーザがログインしたら、自分のプロファイルページにリダイレクトされること。 そしてプロファイルページには、関連する情報が表示されること。

この例は、いくつかの前提条件のもとに作成されています。 まず、起動時の設定のほとんどをプラグインに追い出しました。 これにより、環境設定が簡潔になったのおで テストケースの準備がしやすくなりました。 また、アプリケーションの起動処理が 1 行で書けるようになっています。 また、autoloading の設定を行うことで、 (コントローラやプラグインなどの) 適切なクラスをいちいち require することを考えなくてすむようにしています。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public function setUp()
  4.     {
  5.         $this->bootstrap = array($this, 'appBootstrap');
  6.         parent::setUp();
  7.     }
  8.  
  9.     public function appBootstrap()
  10.     {
  11.         $this->frontController
  12.              ->registerPlugin(new Bugapp_Plugin_Initialize('development'));
  13.     }
  14.  
  15.     public function testCallWithoutActionShouldPullFromIndexAction()
  16.     {
  17.         $this->dispatch('/user');
  18.         $this->assertController('user');
  19.         $this->assertAction('index');
  20.     }
  21.  
  22.     public function testIndexActionShouldContainLoginForm()
  23.     {
  24.         $this->dispatch('/user');
  25.         $this->assertAction('index');
  26.         $this->assertQueryCount('form#loginForm', 1);
  27.     }
  28.  
  29.     public function testValidLoginShouldGoToProfilePage()
  30.     {
  31.         $this->request->setMethod('POST')
  32.               ->setPost(array(
  33.                   'username' => 'foobar',
  34.                   'password' => 'foobar'
  35.               ));
  36.         $this->dispatch('/user/login');
  37.         $this->assertRedirectTo('/user/view');
  38.  
  39.         $this->resetRequest()
  40.              ->resetResponse();
  41.  
  42.         $this->request->setMethod('GET')
  43.              ->setPost(array());
  44.         $this->dispatch('/user/view');
  45.         $this->assertRoute('default');
  46.         $this->assertModule('default');
  47.         $this->assertController('user');
  48.         $this->assertAction('view');
  49.         $this->assertNotRedirect();
  50.         $this->assertQuery('dl');
  51.         $this->assertQueryContentContains('h2', 'User: foobar');
  52.     }
  53. }

この例は、もう少しシンプルに書くこともできます。 ここで示したアサーションのすべてが必須というわけではなく、 単に説明のためだけに用意しているものもあるからです。 アプリケーションのテストがいかにシンプルにできるのか、 この例でご理解いただけることでしょう。

テストケースの起動

Login サンプル で説明したように、すべての MVC テストケースは Zend_Test_PHPUnit_ControllerTestCase を継承しなければなりません。このクラスは PHPUnit_Framework_TestCase を継承しており、 PHPUnit が提供する仕組みやアサーションをすべて使用できます。 またそれに加えて、Zend Framework の MVC 実装に特化した scaffold 機能やアサーションもあります。

MVC アプリケーションをテストするには、まずそれを起動する必要があります。 いくつかの方法がありますが、どの方法になるかは public プロパティ $bootstrap で決まります。

最初に、そして、おそらく最も直接的には、 単純に index.php で行うように Zend_Application インスタンスを作成します。 そして、それを $bootstrap プロパティにアサインします。 一般的に、これは setUp() で行います。 実行されるときに、 parent::setUp() を呼ぶ必要があります。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public function setUp()
  4.     {
  5.         //1段階でアサインしてインスタンス化します。
  6.         $this->bootstrap = new Zend_Application(
  7.             'testing',
  8.             APPLICATION_PATH . '/configs/application.ini'
  9.         );
  10.         parent::setUp();
  11.     }
  12. }

次に、このプロパティでファイルを指定できます。 そうすると、そのファイルはフロントコントローラをディスパッチせず、 単にフロントコントローラ (とアプリケーション固有の設定) を準備するだけの役割となります。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public $bootstrap = '/path/to/bootstrap/file.php'
  4.  
  5.     // ...
  6. }

3番目の方法として、アプリケーションを起動するための PHP コールバックを指定できます。 この方法は Login サンプル で使用しています。使用するコールバックが関数や static メソッドである場合は、クラスレベルで設定できます。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public $bootstrap = array('App', 'bootstrap');
  4.  
  5.     // ...
  6. }

オブジェクトのインスタンスが必要な場合は、 setUp() メソッドを利用することを推奨します。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public function setUp()
  4.     {
  5.         // Bootstrap オブジェクトのインスタンスメソッド 'start' を使用します
  6.         $bootstrap = new Bootstrap('test');
  7.         $this->bootstrap = array($bootstrap, 'start');
  8.         parent::setUp();
  9.     }
  10. }

parent::setUp(); に注目しましょう。 これは必須です。とうのも、Zend_Test_PHPUnit_ControllerTestCasesetUp() メソッドが残りの起動処理 (コールバックの呼び出しも含む) を実行するからです。

通常、 setUp() メソッドは次のようにアプリケーションを起動します。 まずクリーンな環境を読み込んでリクエストの状態を初期化し、 プラグインやヘルパーをすべてリセットし、 フロントコントローラをリセットして リクエストオブジェクトとレスポンスオブジェクトを新しく作成します。 それが終わったら、$bootstrap で指定したファイルを include() するか、 あるいは指定したコールバックを呼び出します。

テストの起動処理は、可能な限りそのアプリケーションの起動処理と同じになるようにしています。 しかし、いくつかの制約もあります。

  • リクエストオブジェクトやレスポンスオブジェクトに独自実装を用意しても、 それが使われることはありません。 Zend_Test_PHPUnit_ControllerTestCase は、 独自のリクエストオブジェクトとレスポンスオブジェクト (それぞれ Zend_Controller_Request_HttpTestCase および Zend_Controller_Response_HttpTestCase) を持っています。これらのオブジェクトには、 指定した方法でリクエスト環境を準備したり 指定した方法で人工的なレスポンスを返したりするメソッドが用意されています。

  • テストサーバに特定の設定を期待してはいけません。 言い換えると、テストの実行環境が特定のサーバ設定になっていることは保証されていないということです。 アプリケーション側から期待してもかまわないのは、 単にルータがリクエストをルーティングしてくれるということだけです。 サーバ固有のヘッダをリクエストオブジェクトに含めてはいけません。

アプリケーションが起動したら、 いよいよテストを作り始めることができます。

コントローラおよび MVC アプリケーションのテスト

起動用の設定を済ませたら、テストの開始です。 テストの方法は PHPUnit テストスイートによるものとほぼ同じですが、 ちょっとした違いがいくつかあります。

まず、テストケースの dispatch() メソッドを用いてテストの URL をディスパッチしなければなりません。

  1. class IndexControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     // ...
  4.  
  5.     public function testHomePage()
  6.     {
  7.         $this->dispatch('/');
  8.         // ...
  9.     }
  10. }

しかし、時にはこれ以外の情報 (GET 変数や POST 変数、 COOKIE 情報など) が必要になることもあります。 これらの情報をリクエストに含めることもできます。

  1. class FooControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     // ...
  4.  
  5.     public function testBarActionShouldReceiveAllParameters()
  6.     {
  7.         // GET 変数を設定します
  8.         $this->request->setQuery(array(
  9.             'foo' => 'bar',
  10.             'bar' => 'baz',
  11.         ));
  12.  
  13.         // POST 変数を設定します
  14.         $this->request->setPost(array(
  15.             'baz'  => 'bat',
  16.             'lame' => 'bogus',
  17.         ));
  18.  
  19.         // クッキーの値を指定します
  20.         $this->request->setCookie('user', 'matthew');
  21.         // あるいは複数の値を指定します
  22.         $this->request->setCookies(array(
  23.             'timestamp' => time(),
  24.             'host'      => 'foobar',
  25.         ));
  26.  
  27.         // ヘッダを設定することもできます
  28.         $this->request->setHeader('X-Requested-With', 'XmlHttpRequest');
  29.  
  30.         // リクエストメソッドを設定します
  31.         $this->request->setMethod('POST');
  32.  
  33.         // ディスパッチします
  34.         $this->dispatch('/foo/bar');
  35.  
  36.         // ...
  37.     }
  38. }

リクエストが準備できたので、次はアサーションを作成してみましょう。

コントローラのテストと Redirector アクションヘルパー

Important

Redirect アクションヘルパーは、 gotoAndExit() メソッドを使うときに exit() ステートメントを発行し、このメソッドのテストを停止させます。 アプリケーションのテスト容易性を考慮して、 リダイレクタではこのメソッドを使わないようにしましょう。

その性質上、リダイレクタアクションヘルパープラグインは リダイレクトしたあと処理を終了します。exit をコールする部分をテストすることはできないので、 Zend_Test_PHPUnit_ControllerTestCase は自動的にリダイレクタでの exit 部分を無効化します。 その結果、テスト時と実際の実行時で挙動が変わってくることがありえます。 リダイレクトが正しく動作することを確実にするには、次のようにします。

  1. class MyController extends Zend_Controller_Action
  2. {
  3.     public function indexAction()
  4.     {
  5.         if($someCondition == true) {
  6.             return $this->_redirect(...);
  7.         } else if($anotherCondition == true) {
  8.             $this->_redirector->gotoSimple("foo");
  9.             return;
  10.         }
  11.  
  12.         // do some stuff here
  13.     }
  14. }
Important

アプリケーションによっては、これだけでは不十分かもしれません。さらに preDispatch() あるいは postDispatch() といったロジックを実行するかもしれないからです。 現状の Zend Test では、これらをうまく処理することはできません。

アサーション

アサーションは、ユニットテストの肝となるものです。 この機能を使うことで、期待する結果と実際の結果が一致することを確かめるのです。 Zend_Test_PHPUnit_ControllerTestCase では数多くのアサーションを用意しており、 MVC アプリケーションやコントローラのテストをよりシンプルにできるようにしています。

CSS セレクタアサーション

CSS セレクタを使うと、 レスポンスの中身に何らかの結果が入っていることを簡単に検証できます。 また、Javascript の UI や AJAX との統合も簡単に行えます。 大半の JS ツールキットは、 CSS セレクタ形式で DOM 要素を取得するための仕組みを持っています。 それと同じ構文で使用できるのです。

この機能は Zend_Dom_Query を用いて実装されており、'Query' アサーションに統合されています。 個々のアサーションの最初の引数に CSS セレクタを指定し、 アサーションの型に応じてオプション引数やエラーメッセージも指定します。 CSS セレクタの書き方の規則については、Zend_Dom_Query の操作方法の章 を参照ください。Query アサーションには次のようなものがあります。

  • assertQuery($path, $message = ''): 指定した CSS セレクタにマッチするひとつあるいは複数の DOM 要素が存在することを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。

  • assertQueryContentContains($path, $match, $message = ''): 指定した CSS セレクタにマッチするひとつあるいは複数の DOM 要素が存在し、そのすくなくともひとつに $match で指定した内容が含まれることを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。

  • assertQueryContentRegex($path, $pattern, $message = ''): 指定した CSS セレクタにマッチするひとつあるいは複数の DOM 要素が存在し、そのすくなくともひとつに正規表現 $pattern にマッチする内容が含まれることを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。

  • assertQueryCount($path, $count, $message = ''): 指定した CSS セレクタにマッチする DOM 要素が、ちょうど $count 個存在することを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。

  • assertQueryCountMin($path, $count, $message = ''): 指定した CSS セレクタにマッチする DOM 要素が、少なくとも $count 個以上存在することを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。 注意: $count に 1 を指定した場合は、単に assertQuery() を使うのと同じ意味となります。

  • assertQueryCountMax($path, $count, $message = ''): 指定した CSS セレクタにマッチする DOM 要素が、最大でも $count 個以下しか存在しないことを表明します。 $message を指定すると、 存在しなかった場合のメッセージの先頭にそれが追加されます。 注意: $count に 1 を指定した場合は、単に assertQuery() を使うのと同じ意味となります。

さらに、上であげたそれぞれに対する否定のアサーションを行う 'Not' 系のメソッドが存在します。 assertNotQuery()assertNotQueryContentContains()assertNotQueryContentRegex() そして assertNotQueryCount() です (min および max については対応するメソッドは存在しませんが、 それは自明なことだからです)。

XPath アサーション

CSS セレクタよりも XPath のほうが使いやすいという開発者もいることでしょう。 そこで、 Query アサーション のすべてのメソッドに対して、同等の動作をする XPath 版のメソッドを用意しています。

  • assertXpath($path, $message = '')

  • assertNotXpath($path, $message = '')

  • assertXpathContentContains($path, $match, $message = '')

  • assertNotXpathContentContains($path, $match, $message = '')

  • assertXpathContentRegex($path, $pattern, $message = '')

  • assertNotXpathContentRegex($path, $pattern, $message = '')

  • assertXpathCount($path, $count, $message = '')

  • assertNotXpathCount($path, $count, $message = '')

  • assertXpathCountMin($path, $count, $message = '')

  • assertNotXpathCountMax($path, $count, $message = '')

リダイレクトアサーション

アクションがリダイレクトを行うこともよくあります。 リダイレクト先をたどらなくても、 Zend_Test_PHPUnit_ControllerTestCase のさまざまなアサーションでそれをテストできます。

  • assertRedirect($message = ''): リダイレクトが発生することを表明します。

  • assertNotRedirect($message = ''): リダイレクトが発生しないことを表明します。

  • assertRedirectTo($url, $message = ''): リダイレクトが発生し、Location ヘッダの値が $url で指定したものであることを表明します。

  • assertNotRedirectTo($url, $message = ''): 「リダイレクトが発生しない」あるいは「リダイレクト先の Location ヘッダの値が $url で指定したものではない」 のいずれかであることを表明します。

  • assertRedirectRegex($pattern, $message = ''): リダイレクトが発生し、Location ヘッダの値が $pattern で指定した正規表現にマッチするものであることを表明します。

  • assertNotRedirectRegex($pattern, $message = ''): 「リダイレクトが発生しない」あるいは「リダイレクト先の Location ヘッダの値が $pattern で指定した正規表現にマッチしない」のいずれかであることを表明します。

レスポンスヘッダアサーション

リダイレクトヘッダのチェックだけでなく、 特定の HTTP のレスポンスコードやヘッダのチェックが必要になることもあります。 たとえば「アクションの結果のレスポンスが 404 か 500 のいずれかであること」 「JSON レスポンスに適切な Content-Type ヘッダが設定されていること」 などです。次のようなアサーションが使用できます。

  • assertResponseCode($code, $message = ''): 指定した HTTP レスポンスコードが返されることを表明します。

  • assertHeader($header, $message = ''): レスポンスに指定したヘッダが含まれることを表明します。

  • assertHeaderContains($header, $match, $message = ''): レスポンスに指定したヘッダが含まれ、 指定した文字列がその中に含まれることを表明します。

  • assertHeaderRegex($header, $pattern, $message = ''): レスポンスに指定したヘッダが含まれ、 その値が指定した正規表現にマッチすることを表明します。

さらに、上であげたそれぞれに対する否定のアサーションを行う 'Not' 系のメソッドが存在します。

リクエストアサーション

最後に実行されたアクションやコントローラ、 そしてモジュールについてのアサーションを行えると便利です。 さらに、どのルートにマッチしたのかを確認したいこともあるでしょう。 以下のアサーションが、その手助けとなります。

  • assertModule($module, $message = ''): 指定したモジュールが、 最後にディスパッチされたアクションで用いられたことを表明します。

  • assertController($controller, $message = ''): 指定したコントローラが、 最後にディスパッチされたアクションで選択されたことを表明します。

  • assertAction($action, $message = ''): 指定したアクションが、直近にディスパッチされたことを表明します。

  • assertRoute($route, $message = ''): 指定した名前のルートが、ルータでマッチしたことを表明します。

そして、それぞれについて否定を表す 'Not' 系のメソッドが存在します。

テスト環境の設定方法とアサーションの作成方法を説明しましたが、 まだまだ戦いは続きます。それでは、 実際のテストシナリオをもとにテストの方法を確認していきましょう。

Example #2 UserController のテスト

ウェブサイトの一般的なタスクである、 ユーザ認証とユーザ登録について考えてみましょう。 今回の例では UserController でこれらを処理することにします。 要件は次のとおりです。

  • ユーザがまだ認証を済ませていない場合は、 どんなアクションが指定されたかにかかわらず 常にコントローラのログインページにリダイレクトされる。

  • ログインフォームのページには、 ログインフォームと新規登録フォームの両方が表示される。

  • 間違った認証情報を入力すると、 ログインフォームに戻る。

  • 正しい認証情報を入力すると、 ユーザのプロファイルページにリダイレクトされる。

  • プロファイルページには、そのユーザのユーザ名が表示される。

  • 認証済みのユーザがログインフォームを訪れると、 そのユーザのプロファイルページにリダイレクトされる。

  • ログアウトしたら、ログインページにリダイレクトされる。

  • 無効なデータが渡された場合は、登録に失敗する。

もちろんこれら以外にも別のテストも必要でしょうが、 今のところはひとまずこれだけにしておきます。

今回のアプリケーションでは、プラグイン 'Initialize' を定義してそれを routeStartup() で実行します。 これによって起動処理をオブジェクト指向でカプセル化することができ、 コールバックを提供しやすくなります。 それではまず、このクラスの基本部分を見ていきましょう。

  1. class Bugapp_Plugin_Initialize extends Zend_Controller_Plugin_Abstract
  2. {
  3.     /**
  4.      * @var Zend_Config
  5.      */
  6.     protected static $_config;
  7.  
  8.     /**
  9.      * @var string 現在の環境
  10.      */
  11.     protected $_env;
  12.  
  13.     /**
  14.      * @var Zend_Controller_Front
  15.      */
  16.     protected $_front;
  17.  
  18.     /**
  19.      * @var string アプリケーションのルートパス
  20.      */
  21.     protected $_root;
  22.  
  23.     /**
  24.      * コンストラクタ
  25.      *
  26.      * 環境、ルートパス、設定を初期化します
  27.      *
  28.      * @param  string $env
  29.      * @param  string|null $root
  30.      * @return void
  31.      */
  32.     public function __construct($env, $root = null)
  33.     {
  34.         $this->_setEnv($env);
  35.         if (null === $root) {
  36.             $root = realpath(dirname(__FILE__) . '/../../../');
  37.         }
  38.         $this->_root = $root;
  39.  
  40.         $this->initPhpConfig();
  41.  
  42.         $this->_front = Zend_Controller_Front::getInstance();
  43.     }
  44.  
  45.     /**
  46.      * ルートの開始処理
  47.      *
  48.      * @return void
  49.      */
  50.     public function routeStartup(Zend_Controller_Request_Abstract $request)
  51.     {
  52.         $this->initDb();
  53.         $this->initHelpers();
  54.         $this->initView();
  55.         $this->initPlugins();
  56.         $this->initRoutes();
  57.         $this->initControllers();
  58.     }
  59.  
  60.     // この後にメソッド定義が続きます...
  61. }

これで、起動用コールバックを次のように作れるようになります。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     public function appBootstrap()
  4.     {
  5.         $controller = $this->getFrontController();
  6.         $controller->registerPlugin(
  7.             new Bugapp_Plugin_Initialize('development')
  8.         );
  9.     }
  10.  
  11.     public function setUp()
  12.     {
  13.         $this->bootstrap = array($this, 'appBootstrap');
  14.         parent::setUp();
  15.     }
  16.  
  17.     // ...
  18. }

ここまでできたら、テストを書くことができます。 しかし、ユーザがログインした状態でのテストはどのように書けばいいでしょう? 簡単な方法は、アプリケーションのロジックを利用する方法です。 resetRequest() メソッドや resetResponse() メソッドを使ってちょっとした細工を行い、 別のリクエストをディスパッチさせます。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     // ...
  4.  
  5.     public function loginUser($user, $password)
  6.     {
  7.         $this->request->setMethod('POST')
  8.                       ->setPost(array(
  9.                           'username' => $user,
  10.                           'password' => $password,
  11.                       ));
  12.         $this->dispatch('/user/login');
  13.         $this->assertRedirectTo('/user/view');
  14.  
  15.         $this->resetRequest()
  16.              ->resetResponse();
  17.  
  18.         $this->request->setPost(array());
  19.  
  20.         // ...
  21.     }
  22.  
  23.     // ...
  24. }

ではテストを書いてみましょう。

  1. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  2. {
  3.     // ...
  4.  
  5.     public function testCallWithoutActionShouldPullFromIndexAction()
  6.     {
  7.         $this->dispatch('/user');
  8.         $this->assertController('user');
  9.         $this->assertAction('index');
  10.     }
  11.  
  12.     public function testLoginFormShouldContainLoginAndRegistrationForms()
  13.     {
  14.         $this->dispatch('/user');
  15.         $this->assertQueryCount('form', 2);
  16.     }
  17.  
  18.     public function testInvalidCredentialsShouldResultInRedisplayOfLoginForm()
  19.     {
  20.         $request = $this->getRequest();
  21.         $request->setMethod('POST')
  22.                 ->setPost(array(
  23.                     'username' => 'bogus',
  24.                     'password' => 'reallyReallyBogus',
  25.                 ));
  26.         $this->dispatch('/user/login');
  27.         $this->assertNotRedirect();
  28.         $this->assertQuery('form');
  29.     }
  30.  
  31.     public function testValidLoginShouldRedirectToProfilePage()
  32.     {
  33.         $this->loginUser('foobar', 'foobar');
  34.     }
  35.  
  36.     public function testAuthenticatedUserShouldHaveCustomizedProfilePage()
  37.     {
  38.         $this->loginUser('foobar', 'foobar');
  39.         $this->request->setMethod('GET');
  40.         $this->dispatch('/user/view');
  41.         $this->assertNotRedirect();
  42.         $this->assertQueryContentContains('h2', 'foobar');
  43.     }
  44.  
  45.     public function
  46.         testAuthenticatedUsersShouldBeRedirectedToProfileWhenVisitingLogin()
  47.     {
  48.         $this->loginUser('foobar', 'foobar');
  49.         $this->request->setMethod('GET');
  50.         $this->dispatch('/user');
  51.         $this->assertRedirectTo('/user/view');
  52.     }
  53.  
  54.     public function testUserShouldRedirectToLoginPageOnLogout()
  55.     {
  56.         $this->loginUser('foobar', 'foobar');
  57.         $this->request->setMethod('GET');
  58.         $this->dispatch('/user/logout');
  59.         $this->assertRedirectTo('/user');
  60.     }
  61.  
  62.     public function testRegistrationShouldFailWithInvalidData()
  63.     {
  64.         $data = array(
  65.             'username' => 'This will not work',
  66.             'email'    => 'this is an invalid email',
  67.             'password' => 'Th1s!s!nv@l1d',
  68.             'passwordVerification' => 'wrong!',
  69.         );
  70.         $request = $this->getRequest();
  71.         $request->setMethod('POST')
  72.                 ->setPost($data);
  73.         $this->dispatch('/user/register');
  74.         $this->assertNotRedirect();
  75.         $this->assertQuery('form .errors');
  76.     }
  77. }

これらは簡潔なものであり、大半は実際の中身までは見ていないことに注意しましょう。 その代わりに、レスポンスコードやヘッダ、そして DOM ノードを見ています。 これにより、期待通りの構造になっているかどうかを検証できるようになり、 新たなコンテンツが追加されるたびにテストを実行しなおすことが避けられます。

ドキュメントの構造を使用してテストを行なっていることに注目しましょう。 たとえば最後のテストでは、"errors" というクラスが指定されているノードをフォームから探しました。 これにより、単にフォームの検証エラーが発生したかどうかだけを確認することができ、 どんなエラーが発生したのかという中身までは気にしなくてすむのです。

このアプリケーションでは、データベースを使うことがあるかもしれません。 そんな場合は、何らかの scaffold を使用してデータベースの初期状態を作成し、 テスト用の設定を行うという作業が各テストの最初に発生します。 PHPUnit にはそのための機能が既に用意されています。 » PHPUnit のドキュメントを参照ください。 テスト時と実運用時には別のデータベースを使用することを推奨します。 また、特に (ファイルあるいはインメモリ形式の) SQLite を使うことを推奨します。どちらも別のサーバを必要とせず、 大半の SQL 構文を使用できます。


導入