phpunit

PHPUnitは、xUnitと呼ばれるテスティング・フレームワークの一つです。

要するに JUnitのphp版です。

Zend Framework (1.6〜) や CakePHP (2.0〜)、Symfony2 もPHPUnitをサポートし、数あるPHPのテスティングフレームワークの中でデファクトスタンダードな存在の様です。

現在のPHPUnitのバージョンは 3.8。

PHP 5.4.7以降でないといけないみたいです。

おいそれとphpのバージョンを上げられないプロジェクトでは、少し古めのPHPUnitで我慢する事になります。その場合、使えない機能がちらほら出てきて悲しい思いをします。

 


なぜ xUnitなのか

一応おさらいというか、自分が思う必要性というか。

判っているヒトには当たり前な話というか。

継続的インテグレーションとかTDDがどーのこーの言う以前に、xUnitでプログラミングと設計が同時進行な感じが堪らないです。右脳で書いちゃうぜみたいな。プログラミングとデバッグが同時進行なメリットも大きいですよね。結果として、テスト効率向上は勿論、デグレ防止にも繋がるんじゃないかと思います。

コマンド1つで何度でも、場合によっては自動でテストを実行できるから、回帰テストとしても。

きちんと書けばですが、つまりは継続的なプログラム改良を助ける事になると。

特に入力値の組み合わせパターンが多いテスト、データの前準備が必要なテストとか、人力でやると死んじゃう。

そもそもNightlyなビルドとか人力ではりーむー。weeklyでも苦しい。でも1週間以上前書いたコードのバグとか見つかったらかなりブルー。

別にxUnitである必要はありませんが、平準化って大事ですし。共通言語化するというか。

教育の面からも、testableなコードを書くクセ付けとして有効かなと。自戒も込めて。

あと忘れてはいけないのは、動くドキュメントとして、動くサンプルコードとしてのテストコードという考え方のメリット。ユーティリティクラス書いたんで使い方とかはxxDocとテストコード見といて、で済ませたいんです。

phperの方なら解って頂けると思うんですけど、phpの関数マニュアルとか、API仕様よりコメント欄のサンプルコードの方が、一発で理解できる場合結構ありませんかね。

見るヒトが居ないとかプログラムと内容が乖離しているとかあまり意味のないドキュメンテーションにはモチベーション上がりませんけど、意味のある事なら頑張って書いちゃえるです。

xUnit単体では効果は限定的であり、開発プロセス全体の最適化とあわせてその手法の一つとして取り入れる事で威力を発揮します。

 


xUnitのデメリット

PGの工数増えますよね。

例えばView の検証は苦手だし、メンテも大変ですよね。

得られるベネフィットと天秤に、ポイントを絞らないと。

ただ特に変化の激しいWebサービスとかはプログラミングの量が増える、というデメリットを帳消しにして余りある威力がありますよね。とりあえずテストコード書けやハゲって感じです。ハゲてへんわ。

ただユニットテストは万能じゃ無いんで。効果的に書くにはスキルも要るでしょうし、カバレッジどこまで上げるかもありますし。

がっつりユニットテスト書いているのにバグだらけ、っていうのんも見たことありますし。

テストはどんどん遅くなるんで、工夫が必要になってきます。

テストデータ生成の回数を減らすとか、テストのスコープを限定するとか、テスト環境を分散するとか。

あと原則として一人一つテスト環境は持ってないとダメですよね。

 


PHPUnitの環境構築

pear を入れてOSのPATHとphpのinclude_path通す

pear config-set auto_discover 1
pear install pear.phpunit.de/PHPUnit

あとはテストコード置き場のディレクトリを作成しときます。

mkdir -p ~/tests/src/

書き方とかは、まぁ、ぐぐって頂くか、マニュアル読む方向で。

纏めると、

extends PHPUnit_Framework_TestCase なクラス

setUp() でテストデータ用意

public な @test アノテーション (or testではじまる) メソッドでテストを書く

アサーションで結果の検証

JUnit 3系 でアノテーションが使える、って感じで大体あっているんじゃないかと。

テストコード実行の実行は、テストクラス単体ではこんな感じ

phpunit ~/tests/src/HogeTest.php

設定ファイルで纏めて実行はこんな感じ

vi ~/tests/phpunit.xml

src

cd ~/tests/

phpunit

テストコードの書き方とかは、PHPUnit でググっても情報少ないし書籍もほぼ無いんで、JUnitで探した方がいいかもです。

考え方は流用できると思うんで。

JUnit本ならコチラがお勧めです。

 


参考にさせて頂いたサイト

第1章 自動テスト – PHPUnit Manual

第4章 PHPUnit 用のテストの書き方 – PHPUnit Manual

[phpunit

PHPUnitは、xUnitと呼ばれるテスティング・フレームワークの一つです。

要するに JUnitのphp版です。

Zend Framework (1.6〜) や CakePHP (2.0〜)、Symfony2 もPHPUnitをサポートし、数あるPHPのテスティングフレームワークの中でデファクトスタンダードな存在の様です。

現在のPHPUnitのバージョンは 3.8。

PHP 5.4.7以降でないといけないみたいです。

おいそれとphpのバージョンを上げられないプロジェクトでは、少し古めのPHPUnitで我慢する事になります。その場合、使えない機能がちらほら出てきて悲しい思いをします。

 


なぜ xUnitなのか

一応おさらいというか、自分が思う必要性というか。

判っているヒトには当たり前な話というか。

継続的インテグレーションとかTDDがどーのこーの言う以前に、xUnitでプログラミングと設計が同時進行な感じが堪らないです。右脳で書いちゃうぜみたいな。プログラミングとデバッグが同時進行なメリットも大きいですよね。結果として、テスト効率向上は勿論、デグレ防止にも繋がるんじゃないかと思います。

コマンド1つで何度でも、場合によっては自動でテストを実行できるから、回帰テストとしても。

きちんと書けばですが、つまりは継続的なプログラム改良を助ける事になると。

特に入力値の組み合わせパターンが多いテスト、データの前準備が必要なテストとか、人力でやると死んじゃう。

そもそもNightlyなビルドとか人力ではりーむー。weeklyでも苦しい。でも1週間以上前書いたコードのバグとか見つかったらかなりブルー。

別にxUnitである必要はありませんが、平準化って大事ですし。共通言語化するというか。

教育の面からも、testableなコードを書くクセ付けとして有効かなと。自戒も込めて。

あと忘れてはいけないのは、動くドキュメントとして、動くサンプルコードとしてのテストコードという考え方のメリット。ユーティリティクラス書いたんで使い方とかはxxDocとテストコード見といて、で済ませたいんです。

phperの方なら解って頂けると思うんですけど、phpの関数マニュアルとか、API仕様よりコメント欄のサンプルコードの方が、一発で理解できる場合結構ありませんかね。

見るヒトが居ないとかプログラムと内容が乖離しているとかあまり意味のないドキュメンテーションにはモチベーション上がりませんけど、意味のある事なら頑張って書いちゃえるです。

xUnit単体では効果は限定的であり、開発プロセス全体の最適化とあわせてその手法の一つとして取り入れる事で威力を発揮します。

 


xUnitのデメリット

PGの工数増えますよね。

例えばView の検証は苦手だし、メンテも大変ですよね。

得られるベネフィットと天秤に、ポイントを絞らないと。

ただ特に変化の激しいWebサービスとかはプログラミングの量が増える、というデメリットを帳消しにして余りある威力がありますよね。とりあえずテストコード書けやハゲって感じです。ハゲてへんわ。

ただユニットテストは万能じゃ無いんで。効果的に書くにはスキルも要るでしょうし、カバレッジどこまで上げるかもありますし。

がっつりユニットテスト書いているのにバグだらけ、っていうのんも見たことありますし。

テストはどんどん遅くなるんで、工夫が必要になってきます。

テストデータ生成の回数を減らすとか、テストのスコープを限定するとか、テスト環境を分散するとか。

あと原則として一人一つテスト環境は持ってないとダメですよね。

 


PHPUnitの環境構築

pear を入れてOSのPATHとphpのinclude_path通す

pear config-set auto_discover 1
pear install pear.phpunit.de/PHPUnit

あとはテストコード置き場のディレクトリを作成しときます。

mkdir -p ~/tests/src/

書き方とかは、まぁ、ぐぐって頂くか、マニュアル読む方向で。

纏めると、

extends PHPUnit_Framework_TestCase なクラス

setUp() でテストデータ用意

public な @test アノテーション (or testではじまる) メソッドでテストを書く

アサーションで結果の検証

JUnit 3系 でアノテーションが使える、って感じで大体あっているんじゃないかと。

テストコード実行の実行は、テストクラス単体ではこんな感じ

phpunit ~/tests/src/HogeTest.php

設定ファイルで纏めて実行はこんな感じ

vi ~/tests/phpunit.xml

src

cd ~/tests/

phpunit

テストコードの書き方とかは、PHPUnit でググっても情報少ないし書籍もほぼ無いんで、JUnitで探した方がいいかもです。

考え方は流用できると思うんで。

JUnit本ならコチラがお勧めです。

 


参考にさせて頂いたサイト

第1章 自動テスト – PHPUnit Manual

第4章 PHPUnit 用のテストの書き方 – PHPUnit Manual

]5