phpunit でテスト駆動開発を始めよう
DESCRIPTION
TRANSCRIPT
PHPUnit でテスト駆動開発を
始めよう@yuya_takeyama
このスライドは以前の発表を抜粋・再編集・加筆してお送りします
http://blog.yuyat.jp/archives/1386
アジェンダ
•PHPUnit とは何か
•何故ユニットテストを書くか
•免責事項 (PHPUnit 的な意味で)
•蛇足 : オレはこう思う
What’sPHPUnit?
PHPUnit とは
•テスティングフレームワーク
•ユニットテストを書く
•比較的簡単に書ける
•多機能
何故 PHPUnit か
•豊富なドキュメント
•日本語訳も充実(PHP マニュアルでもおなじみ高木正弘さん)
•豊富な利用実績 (ZF, Symfony2, etc)
http://www.phpunit.de/manual/current/ja/
http://www.phpunit.de/manual/current/ja/
これ読むだけでもかなり勉強になるのでオススメです
class CalculatorTest extends PHPUnit_Framework_TestCase{ public function setUp() { $this->calc = new Calculator; }
public function test_add_引数の和を返す() { $result = $this->calc->add(1, 2); $this->assertSame(3, $result); }}
class CalculatorTest extends PHPUnit_Framework_TestCase{ public function setUp() { $this->calc = new Calculator; }
public function test_add_引数の和を返す() { $result = $this->calc->add(1, 2); $this->assertSame(3, $result); }}
1
テストに必要な物の用意
class CalculatorTest extends PHPUnit_Framework_TestCase{ public function setUp() { $this->calc = new Calculator; }
public function test_add_引数の和を返す() { $result = $this->calc->add(1, 2); $this->assertSame(3, $result); }}
2
テスト対象の実行
class CalculatorTest extends PHPUnit_Framework_TestCase{ public function setUp() { $this->calc = new Calculator; }
public function test_add_引数の和を返す() { $result = $this->calc->add(1, 2); $this->assertSame(3, $result); }}
3
実行結果の検証 (アサーション)
WhyUnit-test?
ドキュメントとして
•Tests as Documentation
•API の一覧
•動作するサンプルコード
回帰テストとして
•リグレッションテストともいう
•ある修正が新たなバグを生んでいないか
•同じ過ちを繰り返さないため
リファクタリングとは
•振る舞いを帰ること無く
•ソースコードの内部構造を
•変更すること
•ソースコードの体質改善
設計のためのテスト
•Test Driven Design
•ライブラリは API が 9 割
•API のユーザビリティテスト
•リファクタリングで継続的改
テストは質のためならず
設計のためのテスト•オブジェクト指向の原則や
•デザインパターンを武器に
•テスタビリティの高いコードを書き
•リファクタリングで継続的改
テストを中心に据えることで機能・設計を継続的に改善することができる
何故テストを書くか•ドキュメントとして
•回帰テストとして
•設計のため
•リファクタリングのため
•継続的改善のため
免責事項(PHPUnit 的な意味で)
テストを書けば全てが解決するわけではなく, テストを書くことで新たに起こる問題もある
それらの問題を何でも PHPUnit や TDD のせいにするのではなく, 妥協点を見つける必要がある
という話をします
Q. テストを書いていたら開発工数が増えるんだが!!!
A. 冗長化して書いているので当然です
http://d.hatena.ne.jp/nowokay/20120222
テストを書くポイントを選ぶ•やみくもに書けばいいというものではない
•品質が求められる部分
•頻繁に変更が起こり壊れやすい部分
•不安を感じる部分
•初期コストをかけることで, あとで回収できるかどうか
テストもリスク/コスト
•テストを書く時間
•テストをメンテする時間
•コストに見合った対価が得られるか
•カバレッジが同じならテストは少ない方が良い
•可読性重要
Q. テストを書いても開発が駆動 (Drive) されないのだが!!!
A. 今作っているものに TDD がフィットしてないのでは?
TDD が向かないもの
•自分が作ろうとしているものが全くイメージできない場合
•開発の初期段階で, 作ろうとしているもの自体がコロコロ変わる場合
•テストを書こうとすることで, これらの問題に早期に気づくことができる (という話もある)
とりあえず動くものを作ることが大事
http://d.hatena.ne.jp/sotarok/20120105/1325698126
テストファーストが絶対ではない
(と, 個人的には思ってます)
http://www.slideshare.net/t_wada/javaja-tdd-2nd
テストは後からでも書けるし後からでも書くべき
※やみくもにテストを書いて痛い目を見ることで得られるものがあることも付記しておきます
蛇足 : オレはこう思う
プログラマの「オレが全部書き直してやんよ!」病
について
オレが全部(ry
•酷いレガシーコードの塊
•こんなの読んでられない!!
•全部書き直した方が早いのでは???
オレが全部(ry
•酷いレガシーコードの塊
•こんなの読んでられない!!
•全部書き直した方が早いのでは???
本当にそれで
いいのか?
解決したい問題は何か
レガシーコードが抱える問題
•理解するのに時間がかかる
•ちょっと改修するとすぐ壊れる
•拡張が著しく困難
要約すると
レガシーコードが抱える問題
•「オレ」が気に入らない
解決したい問題は何か
全部書き換えればレガシーコードは無くなるのか
短期的には Yes であることもある
長期的には大体 No
コードは腐る
全部書き換える前にコードを腐らせない技術を身につける必要がある
レガシーコードと
立ち向かう勇気
...を, 身につけるためにこれの読書会とかしたいですね
ご清聴ありがとうございました