UnitTestのためのクラス設計

7,958 views

Published on

Published in: Self Improvement
1 Comment
15 Likes
Statistics
Notes
No Downloads
Views
Total views
7,958
On SlideShare
0
From Embeds
0
Number of Embeds
769
Actions
Shares
0
Downloads
47
Comments
1
Likes
15
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • ユニットテストの説明に前に本講義で多用されるオブジェクト指向というものについて説明しておこうと思います。\nオブジェクト指向とは何か?  というとよくある説明として「モノを中心にしたプログラミングのことだよ。 $apple->color = 'red'; みたいなね」 のようなものを見かけます。\n実際にそれは正しし、分かっている人には分かり易いのですが、分からない人にとってはただでさえ分からないところを一層煙に巻かれる状態になり易いので、別のアプローチから簡単に説明します。\nデータ構造とアルゴリズムをワンセットにした単位で扱うプログラミング手法のことです。構造体に変数と関数ポインタをセットにしたものだと思えば良いです。\nその関数ポインタで呼び出した内部で、その構造体の変数を"$this"として直接アクセスできるだけですね。PHPで言う場合、構造体ってハッシュのことだと思えば良いです。\n以下のコードは配列とクロージャを使ってイメージを表現したコードです。\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 人間さんはテストしないですか?\n
  • \n
  • \n
  • 結合テストで確認できるのはインターフェースが\n一致しているということだけです。\n\n
  • ユニットテストっていうのは単体テストのことです。ただし、ここではユニットテストと言う場合、オブジェクト指向プログミングにおけるxUnitを用いたクラス単位のユニットテストのことを指します。JavaならばJUnit、.NETならば NUnit、PHPならばPHPUnitを使います。\n\n
  • \n
  • \n
  • \n
  • プログラムとして保存する「テスト仕様書」であり「エビデンス」であり\n「プログラムの使い方を説明するドキュメント」であると考えれば良いです。\n他に、「無駄に複雑なコードが書けなくなる」というメリットも有ります。\n最低限「UnitTestが書けるレベルのコード」ということが保証されます。\n
  • 3つ目は気になるところだと思うのですが、\nクラス境界、システム境界のインターフェースに齟齬が\nあるという種類のバグは検出出来ません\n
  • \n
  • \n
  • こんなコマンド打つと実行できるよ\n
  • \n
  • \n
  • Unitテストは単体テストなので "クラス単体" をテストします。\n依存を排除したクラス設計をしなければなりません。\n\n\n
  • 依存を排除する理由はつまるところ、これです。\n
  • モックを作るコードを説明する。\n・メソッドの入力の検証\n・出力の固定\nについて説明する\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • DBWrapperをモックにして、コンストラクタの引数で渡しています。\n\nモックにして期待通りのSQL文が渡されることの確認と\nDBが返した値をそのまま返却することを確認しています。\n図中では畳んでますが、getTestCDで配列を定義しています。\n\n
  • \n
  • FileManagerをモックにしてセッタで設定しています。\nまた、自身のfindに対する依存があるため、\n自身をモック化してfindが返す値を固定しています。\n\n
  • \n
  • エスケープのテスト\n\n何にも依存しないユーティリティのようなものなので、ままテストできます。\n
  • ラッパーのことです\n
  • \n
  • \n
  • \n
  • 引数で渡すにせよ関連するクラスはメンバ変数にしてしまうのが、\nUnitTest的には便利だし、オブジェクト指向の設計的にも理にかなってることが多いはず。\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 人間さんはテストしないですか?\n
  • \n
  • 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

    ×