- summary CI and UnitTest
疎結合でリクエスト状態を持たない「リソース指向設計」と、モデル(リソース)のCLI利用、ページリソース等のBEARのリソース指向とサービスオブジェクトの自由な入れ替えが可能なサービスロケータがユニットテストを支援します。
またテストやCI(継続開発)がスムーズに利用できるよに、プロジェクトに設定ファイルが最初から用意されているので、プロジェクトを作成した段階でantやphpunitが使えます
※v0.9.0以降の機能です。
ユニットテストやCIに必要なライブラリをインストールします。
* [http://www.phpunit.de/manual/3.6/ja/installation.html PHPUnit のインストール]
[http://www.bear-project.net/blog/2011/05/php%E3%82%82%E3%82%84%E3%82%89%E3%81%AA%E3%81%8D%E3%82%83jenkins/ PHPもやらなきゃJenkins]
実行時間の分析やコールグラフの出力を行うには、下記の設定が必要です。
xhprofはFacebookの開発したWebで利用可能なプロファイラです。 PHPエクステンション「Xdebug」をインストールします。
* [http://xdebug.org/ Xdebug] * [http://pecl.php.net/package/xhprof XHPROF] * [http://www.graphviz.org/ Graphviz]
BEARアプリケーションの[App.php]で、[App::init]内に、以下のようにスクリプトを呼ぶことで、xhprof機能が有効化されます。
xhprof のブランチでプロファイルの履歴が利用可能なXH GUIも利用可能です。
BEARアプリケーションの[App.php]で、[App::init]内に、以下のようにスクリプトを呼ぶことで、XH GUI機能が有効化されます。(前述のxhprof を有効にしていた場合は、start.phpにstartxh.phpに置換することで、有効化されるように変更されます。)
XH GUIはmysqlを利用します。path/to/BEAR/data/xhprof/にあるREADMEを参照してdbを用意します。
PHPCSにはデフォルトでPEAR, Zend, Squiz等のコード規約ファイルが用意されてますがその3つを元に再編成したBEARのコード規約xmlが用意されています。
規約のインストールを確認します。
Zend Code Analyzer 以前ZendStudioに付属していたものですが、現在入手難です。(最新バージョンには付属しません)利用すれば未使用変数の検知などコードの分析ができます。
phpcsが使用します。あるなら以下のコマンドでsetします。
HTTP越しのテストを行う場合にはテスト対象のサイトではコンポーネントをテストされる用のものに変更します。以下のようにApp.phpで$bearModeでテストモードを持つのが良いでしょう。
※`BEAR_Log`サービスの実クラスが`BEAR_Log_Test`になり、テストクライアントから対象サイトのリソースリクエストやフォームバリデーション情報がHTTP経由で伝わるようになります。
またセッションが不要になる場合にはApp.phpまたはbootstrap.phpで以下のようにします。サービスレジストリの`BEAR_Session`サービスの実クラスを`BEAR_Session_Test`でセットすると際のセッションの書き込み読み出しは行われません。
bear init-appで作成した新規プロジェクトファイルのトップ階層にant/JenkinsやPHPUnitで使うbuild.xmlとphpunit.xml.distが含まれてるのでプロジェクトファイルを作った時からant/やphpunitコマンドを引数なしで利用できます。 ※従来のプロジェクトでもこのファイルを利用できます。その場合テストはtests/に置いてください。
新規example.appを作成して確認
以下のテストが行えるクラスが用意されてます。
* リソーステスト * ページHTMLテスト * ページValueテスト * ページのリソースリクエストテスト * フォームテスト
ページHTMLテストはページが出力するHTMLのテストで、ページバリューテストとはページにセットされた値のテストです。
このうちページバリューテストとフォームテストはHTTP越しの実際にGET/POSTをサブミットするテストになり、専用のサイトを用意する必要があります。
リソース単体でのテストです。この例では対象リソースのcodeとbodyを確認しています。
ページの出力するHTMLをテストします。htdocs/下にあるページをpage://のスキーマを持つページリソースとして扱い出力モードをHTMLにしてHTMLを検査します。
uriはページのクラスです。メソッドがreadのときでonInit($args)がコールされます。valuesで指定した値が$argsに渡されます。outputモードがhtmlの時はdsiplay()でレンダリングしたHTML、valueの時はページにsetされた内容が結果になります。
read以外のcreate, update, deleteメソッドの場合はonAction($submit)がコールされます。その場合valuesで指定した値が$submitに渡されます。メソッドの違いはありません。
HTMLのDOM要素取得は`Zend_Dom_Query`を利用した`BEAR_Test_Query`クラスを用います。CSSセレクタ(JQueryと同じ方式)でDOMを指定します。FireBugを用いれば簡単に表示されたページからCSSセレクタを取得することができます。
ページングもサポートしています。以下のサンプルでhtdocs/resource/link/pager.phpページの`Resource_Link_Pager`ページクラスで出力されるページのうち2ページ目をテストに現れる要素をテストしています。
Cookieやクエリー等のHTTPリクエストの条件によってページがリソースにどういうリクエストを行うかというページのリソースリクエストのテストが行えます。MVCでいうとコントローラーのテストになるかと思います。
リソース結果や実装によらずに、特定HTTPリクエストによるページの働き(リソースリクエスト)をテストします。
下の例は`?id=1`のクエリーを付けてリクエストしたページが内部のROリソースに対して`read Entry?id=1`のリクエストを出しているかをテストしているコードです。`BEAR_Test_Client`はPEAR::HTTP_Request2を継承しているクラスです。CookieやHeader等様々なリクエスト状態を作り出す事ができます。
フォームに実際に値をサブミットして内部のフォームのバリデーションをテストします。画面に表示されたエラー出力などを利用するのではなく、内部のフォームバリデーション結果情報をHTTP経由で取得します。
このためHTTPの制約を受けるのでより現実に即したサブミットテストが可能です。
以下のサンプルではフォームのバリデーションNGの確認をしています。フォームエラーの時に表示される文字列でエラーの種類の判断しています。
複数のフォームがあるページではフォームの名前を指定します。