投稿者: editor

■ フォワード(forward()) のテスト

object isForwardedTo(string $moduleName, string $actionName [, string $position])

モジュール $ModuleName のアクション $actionName に遷移したかをテストします
例: foo/index が boo/index にフォワードしたかを確認する

$t->get(“foo/index”)->isForwardedTo(“boo”, “index”);

 
■ リダイレクト(redirect()) のテスト

object isRedirected([boolean $boolean])

リダイレクトの要求があったかどうかをテストする。$boolean に false が指定された場合、失敗を期待する。

object followRedirect()

要求するリダイレクト先に遷移する。リダイレクト要求がないのに行った場合、例外が投げられる。
 
例: foo/index が boo/index にリダイレクト要求するかを確認する

$browser->get(“foo/index”)->
  isRedirected()->followRedirect()->
  isRequestParameter(‘module’, ‘boo’)->
  isRequestParameter(‘action’, ‘index’);

 
間違ったリダイレクトテスト方法:

object isResponseHeader($key, $value)

を使って

$browser->isResponseHeader(“Location”, “/module/action”)

とするのは間違いです。Location ヘッダは http://frontend-test/index.php/module/action のような絶対 URL になっている上、action が index の場合 action の指定が省略されるため、完全一致チェックの isResponseHeader() メソッドは不適です。

Xcache は pecl に登録されているのですが, windows だと

pecl install xdebug

としてもビルドできませんし、PHP 公式サイトの pecl モジュールのバイナリ版パッケージダウンロードにも含まれていません。
 
配布サイトを探したところ、Xdebug 公式サイトにはちゃんと Windows 版バイナリが配布されていました。
 
参考:
– Xdebug Instration(xdebug.org)
– Re: xdebug install error(xdebug-general ML)

symfony でのテストは機能テスト(functional test)、単体テスト(unit test)が標準でサポートされており、それぞれ以下の特徴があります。
 
□機能テスト
– モジュール生成時に test/functional に自動生成される。
– test/{$app}/{$module}ActionsTest.php というファイル名($app,$module はそれぞれテスト対象のアプリケーション名とモジュール名)
– テスト用仮想 symfony サイトブラウザ クラスの sfTestBrowser を使ったモジュール単位のテストが中心。
– 最初からデフォルトのテスト実装がある
  (ver 1.0.6 時点のデフォルトテスト実装は、モジュールの index アクションが初期のままではないかをテストするというもの)
– テスト実行は

symfony test-functional <appname>

  もしくは

symfony test-all

  で行う
 
□単体テスト
– 機能テストのような自動生成はされないが、test/bootstrap/unit.php をインクルードすることで容易にテストを作成可能。
– test/unit/{$testName}Test.php というファイル名($testName は任意の名前)
– 汎用単体テストクラス lime_test を使った、ライブラリ等のクラスを対象にした個別のテストが中心。
– テスト実行は

symfony test-unit

  もしくは

symfony test-all

  で行う
 
なお、単体、機能どちらのテストも

php test/functional/appname/fooActionsTest.php

のように PHP スクリプトとして実行すると、そのテストだけを実行することができます。
このようにすることで、失敗したテストがどの項目で失敗したかを調べることができます。
 
■sfTestBrowser クラス
sfBrowser クラスのテスト用実装版(sfBrowser の子クラス)。
sfBrowser クラスはTCP 等ネットワーク通信を伴わずに symfony サイト内ページのブラウジング可能な仮想ブラウザ実装です。
 
■lime_test クラス
lime の汎用単体テストクラス。
lime は symfony チーム開発のユニットテストユーティリティです。
 
備考:
 どちらのクラスについても、メソッドの戻り値いがオブジェクト自身のインスタンスを返してくれるので

$t->get(…)->is…(…)->is…(…)

のようにテストのチェインができるため、SimpleTest などの xUnit 互換のものより記述が容易になっています。
参考:
– sfTestBrowser (symfony API)
– sfBrowser (symfony API)
– lime_test class
 (lime_test クラスの phpdoc ドキュメント)
– 新しく採用されたテスティングフレームワークlimeの紹介(symfony で開発日記)
 lime_test クラスメソッドの日本語説明など。
– Chapter 15 – Unit And Fanctional Testing(The Definitive Guide to symfony)
– 15章 単体テストと機能テスト(上のリンクの日本語訳版)

APD(Advanced PHP Debugger)、便利ですよね。
 
APD の使い方について書いてあるページは多々あれど、pprofp についてはあまり触れられていなかったので、手前味噌ですが pprofp -h を日本語訳＋捕捉してみました。
 
書式(APD ver. 0.9):

pprofp <オプション> <解析するファイル>

 
並び順を指定するオプション:
  -a クラス、関数名のアルファベット順に表示する
  -l 関数の呼び出し回数順に表示する
  -m 関数呼び出し中のメモリ使用量順に表示する
  -r 関数の実際の処理時間(real time)順に表示する
  -R 関数の実際の処理時間順に表示する(子関数−関数内での関数呼び出し−の処理時間も含む)
  -s 関数のシステムモードでの処理時間(system time)順に表示する
  -S 関数のシステムモードでの処理時間順に表示する(子関数の処理時間も含む)
  -u 関数のユーザモードでの処理時間(user time)順に表示する
  -U 関数のユーザモードでの処理時間順に表示する(子関数の処理時間も含む)
  -v 関数の平均処理時間順に表示する
  -z 関数のユーザモード、システムモードの処理時間の合計順に表示する(省略時のデフォルト)
  
表示形式についてのオプション:
  -c 関数のコールツリーの横に実際の経過時間をつけて表示する(-t または -T とともに指定)
  -i PHP ビルトイン関数を出力に含めない
  -O <数値> 関数のリスト表示で最大何個の関数まで表示するか(デフォルトは 15 個)
  -t 関数のコールツリーを短縮して表示する
  -T 関数のコールツリーを短縮せず表示する
 
– – – –
捕捉:
処理を追う場合はコールツリー(-t あるいは -T)を使うと便利です。
-t と -T の違いは、
-T は

    doSomething
       define
       define
       define
       define
       echo

のように、同じ関数呼び出しが続いた場合もそのまま表示しますが、-t にすると

     doSomething
       define (4x)
       echo

のように、連続する関数呼び出しを一行に縮めて表示することで出力を短縮します。