PHPUnit でテスト駆動開発を始めよう

27,799 views

Published on

Published in: Technology
1 Comment
69 Likes
Statistics
Notes
No Downloads
Views
Total views
27,799
On SlideShare
0
From Embeds
0
Number of Embeds
1,879
Actions
Shares
0
Downloads
113
Comments
1
Likes
69
Embeds 0
No embeds

No notes for slide

PHPUnit でテスト駆動開発を始めよう

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

×