Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
UnitTestのための  クラス設計    t_ishida
自己紹介名前:石田 武士(@t_ishida)所属:アライドアーキテクツ システム部
注意日頃UnitTestしている人には当たり前の話しかしませんPHPUnitそのもの使い方は説明しませんこのセッションは過去UnitTestにトライしてよく分からなかった、もしくは挫折した人に最適化されています
では、早速
テストしてますか?
テストしてますよ何度もブラウザから叩いて、こっちの分岐入った「っぽい」し何度もブラウザから叩いて、期待通りの回数ループしてる「っぽい」し何度もブラウザから叩いて、期待通りのメソッド呼び出した「っぽい」し
テストしてますよ何度もブラウザから叩いて、こっちの分岐入った「っぽい」し    死亡フラグ何度もブラウザから叩いて、期待通りの回数ループしてる「っぽい」し何度もブラウザから叩いて、期待通りのメソッド呼び出した「っぽい」し
本当にテストしてますか?リロードデバッグですか?実行タイミングが同じだというだけで、関連の無いコードを同じ場所に追記しまくってませんか?それをリロードでデバッグして「テストをしないで」リリースしていませんか?
本当にテストしてますか?リロードデバッグですか?実行タイミングが同じだというだけで、関連の無い      死亡フラグコードを同じ場所に追記しまくってませんか?それをリロードでデバッグして「テストをしないで」リリースしていませんか?結合テストだけ...
にんげんさんてすとしないです?
だって・・・DBが絡むから値固定できないしファイルに吐きだすから値検証できないしブラウザから入力しないとダメだし
だって・・・DBが絡むから値固定できないし   死亡フラグファイルに吐きだすから値検証できないしブラウザから入力しないとダメだし
結合テストをして意味があるのは単体テストをやり尽くしたあ    とからです
UnitTestってなに?身も蓋もない言い方をすれば単体テストただし、本セッションで言う単体テストはxUnit系テスト、主にPHPUnitのテストメソッドに色んなパターンの引数を渡して戻り値が合ってるか比べるだけです
つまり、こんなコードを
こうテスト
UnitTestの考え方“単体”での確認が出来れば良い故に呼んでるメソッドの先の正しさは気にしなくて良い(その先の正しさは、それ単体で確認するから)メソッド単体での正しさを徹底的に確認する
UnitTestのメリット環境から切り離してロジック単体をテストできるプログラムとして保存するから何度でも実行出来る。そして速い。(回帰テスト自動化)電算機のテストは正確 ("hoge" != hoge )
UnitTestのデメリットテストを作るのは時間がかかる場合によってはテストのためにクラス設計を歪める必要がある必ずしも、それで全てのバグを検出することが出来ないので過信は禁物
だからと言って、単体テストしない理由には  なりません
ここから本題
UnitTestのためのクラス設計 UnitTestを意識してクラス設計する必要がある 故に既存のコードをテストに入れるのは大変 どれだけ大変かはレガシーコード改善ガイド を読むと良いです
UnitTestのための  クラス設計の指針強い“依存”を徹底的に排除する クラス間の依存 外部システムへの依存複雑度を下げる
モックそのクラスのように振る舞うダミーのことダミーで入力を検証するダミーで出力を固定する
こういうこと
モックモックを使うということはオブジェクトを差し替えるということ
モックを使うための注意  つまり・・・
モックを使うための注意メソッド内で new してたら差し替えられないstaticメソッド呼び出しは差し替えられない組み込み関数は差し替えられないfinal な クラスも差し替えられない(モックは継承して作る)
依存の排除(クラス間の依存) コンストラクタやメソッドの引数でオブジェ クトを渡す(ファクトリを渡すのも可) セッタで上書き可能なメンバ変数にする
オブジェクト渡し
オブジェクト渡し
セッタで上書き
セッタで上書き
おまけ(依存なし)
依存の排除(外部システム) プロキシパターン
プロキシパターンDBなんか文字列(SQL文)渡したら配列を返すク         ラスです
プロキシパターンファイルの読み込みなんか文字列(path)を渡し  たら文字列を返すただのメソッドです
複雑度を下げる同じタイミングで実行されるからと言って関連の無いコードを同じ場所に書かないifの入れ子になったらメソッドを分割するループの中は別メソッドにする(走査と操作は分ける)
ざっくばらんなまとめそのクラスに関連するオブジェクトはメンバ変数にするメンバ変数はセッターで上書き可能にするメソッドは小まめに分ける外部システムとの絡みはラッパーを作る
テストしない理由?テスト書いている時間がないから上司がテストに対する理解がなくて時間とらせてくれないからあとで書くから複雑過ぎてテストが書けないから
テストしない理由?テスト書いている時間がないから   死亡フラグ上司がテストに対する理解がなくて時間とらせてくれないからあとで書くから複雑過ぎてテストが書けないから
時間無くてテスト書けないそれは手動でテストしている時間も無いはずなのでリリースしてはならないコードです
上司の理解を得られない理解を得る必要はありません勝手に書いてください自分の時間と健康と心の平穏を守るためにやるのです
複雑過ぎてテスト書けないそれは、そもそも手動でもテストできませんメソッドを分割して複雑度を下げてください
あとで書く絶対にあとで書きません
書いておけば妖精さんがテ  ストしてくれます
ご清聴ありがとうございました    http://tech.aainc.co.jp
Upcoming SlideShare
Loading in …5
×

UnitTestのためのクラス設計

0 views

Published on

Published in: Self Improvement

UnitTestのためのクラス設計

  1. 1. UnitTestのための クラス設計 t_ishida
  2. 2. 自己紹介名前:石田 武士(@t_ishida)所属:アライドアーキテクツ システム部
  3. 3. 注意日頃UnitTestしている人には当たり前の話しかしませんPHPUnitそのもの使い方は説明しませんこのセッションは過去UnitTestにトライしてよく分からなかった、もしくは挫折した人に最適化されています
  4. 4. では、早速
  5. 5. テストしてますか?
  6. 6. テストしてますよ何度もブラウザから叩いて、こっちの分岐入った「っぽい」し何度もブラウザから叩いて、期待通りの回数ループしてる「っぽい」し何度もブラウザから叩いて、期待通りのメソッド呼び出した「っぽい」し
  7. 7. テストしてますよ何度もブラウザから叩いて、こっちの分岐入った「っぽい」し 死亡フラグ何度もブラウザから叩いて、期待通りの回数ループしてる「っぽい」し何度もブラウザから叩いて、期待通りのメソッド呼び出した「っぽい」し
  8. 8. 本当にテストしてますか?リロードデバッグですか?実行タイミングが同じだというだけで、関連の無いコードを同じ場所に追記しまくってませんか?それをリロードでデバッグして「テストをしないで」リリースしていませんか?
  9. 9. 本当にテストしてますか?リロードデバッグですか?実行タイミングが同じだというだけで、関連の無い 死亡フラグコードを同じ場所に追記しまくってませんか?それをリロードでデバッグして「テストをしないで」リリースしていませんか?結合テストだけしてテストした気になっていませんか?
  10. 10. にんげんさんてすとしないです?
  11. 11. だって・・・DBが絡むから値固定できないしファイルに吐きだすから値検証できないしブラウザから入力しないとダメだし
  12. 12. だって・・・DBが絡むから値固定できないし 死亡フラグファイルに吐きだすから値検証できないしブラウザから入力しないとダメだし
  13. 13. 結合テストをして意味があるのは単体テストをやり尽くしたあ とからです
  14. 14. UnitTestってなに?身も蓋もない言い方をすれば単体テストただし、本セッションで言う単体テストはxUnit系テスト、主にPHPUnitのテストメソッドに色んなパターンの引数を渡して戻り値が合ってるか比べるだけです
  15. 15. つまり、こんなコードを
  16. 16. こうテスト
  17. 17. UnitTestの考え方“単体”での確認が出来れば良い故に呼んでるメソッドの先の正しさは気にしなくて良い(その先の正しさは、それ単体で確認するから)メソッド単体での正しさを徹底的に確認する
  18. 18. UnitTestのメリット環境から切り離してロジック単体をテストできるプログラムとして保存するから何度でも実行出来る。そして速い。(回帰テスト自動化)電算機のテストは正確 ("hoge" != hoge )
  19. 19. UnitTestのデメリットテストを作るのは時間がかかる場合によってはテストのためにクラス設計を歪める必要がある必ずしも、それで全てのバグを検出することが出来ないので過信は禁物
  20. 20. だからと言って、単体テストしない理由には なりません
  21. 21. ここから本題
  22. 22. UnitTestのためのクラス設計 UnitTestを意識してクラス設計する必要がある 故に既存のコードをテストに入れるのは大変 どれだけ大変かはレガシーコード改善ガイド を読むと良いです
  23. 23. UnitTestのための クラス設計の指針強い“依存”を徹底的に排除する クラス間の依存 外部システムへの依存複雑度を下げる
  24. 24. モックそのクラスのように振る舞うダミーのことダミーで入力を検証するダミーで出力を固定する
  25. 25. こういうこと
  26. 26. モックモックを使うということはオブジェクトを差し替えるということ
  27. 27. モックを使うための注意 つまり・・・
  28. 28. モックを使うための注意メソッド内で new してたら差し替えられないstaticメソッド呼び出しは差し替えられない組み込み関数は差し替えられないfinal な クラスも差し替えられない(モックは継承して作る)
  29. 29. 依存の排除(クラス間の依存) コンストラクタやメソッドの引数でオブジェ クトを渡す(ファクトリを渡すのも可) セッタで上書き可能なメンバ変数にする
  30. 30. オブジェクト渡し
  31. 31. オブジェクト渡し
  32. 32. セッタで上書き
  33. 33. セッタで上書き
  34. 34. おまけ(依存なし)
  35. 35. 依存の排除(外部システム) プロキシパターン
  36. 36. プロキシパターンDBなんか文字列(SQL文)渡したら配列を返すク ラスです
  37. 37. プロキシパターンファイルの読み込みなんか文字列(path)を渡し たら文字列を返すただのメソッドです
  38. 38. 複雑度を下げる同じタイミングで実行されるからと言って関連の無いコードを同じ場所に書かないifの入れ子になったらメソッドを分割するループの中は別メソッドにする(走査と操作は分ける)
  39. 39. ざっくばらんなまとめそのクラスに関連するオブジェクトはメンバ変数にするメンバ変数はセッターで上書き可能にするメソッドは小まめに分ける外部システムとの絡みはラッパーを作る
  40. 40. テストしない理由?テスト書いている時間がないから上司がテストに対する理解がなくて時間とらせてくれないからあとで書くから複雑過ぎてテストが書けないから
  41. 41. テストしない理由?テスト書いている時間がないから 死亡フラグ上司がテストに対する理解がなくて時間とらせてくれないからあとで書くから複雑過ぎてテストが書けないから
  42. 42. 時間無くてテスト書けないそれは手動でテストしている時間も無いはずなのでリリースしてはならないコードです
  43. 43. 上司の理解を得られない理解を得る必要はありません勝手に書いてください自分の時間と健康と心の平穏を守るためにやるのです
  44. 44. 複雑過ぎてテスト書けないそれは、そもそも手動でもテストできませんメソッドを分割して複雑度を下げてください
  45. 45. あとで書く絶対にあとで書きません
  46. 46. 書いておけば妖精さんがテ ストしてくれます
  47. 47. ご清聴ありがとうございました http://tech.aainc.co.jp

×