TDD を自分の道具にしよう
1 like1,105 views
わんくま同盟 名古屋勉強会#20(1/14)のLT資料です。 http://www.wankuma.com/seminar/20120114nagoya20/
TDD を自分の道具にしよう
- 1. TDDを自分の道具にしよう id:yujiorama @yujiorama わんくま同盟 名古屋勉強会 #20
- 2. 自己紹介 • 千葉から来ました(たぶん初めて?) • n次請けシステム開発屋 • 技術リードみたいなことをしたり、PLみたいな ことをしてます • Cが好きです。C++はもっと好きです。 • (一番好きなのはRubyです) わんくま同盟 名古屋勉強会 #20
- 3. 私たちの開発の進め方を変 えてみませんか？ わんくま同盟 名古屋勉強会 #20
- 4. アジェンダ • 仕様化テストを書きましょう • 設計しましょう • リファクタリングをしましょう • テストもリファクタリングしましょう • テストが何を保証しているのか思い出しましょ う • 最終的に残るものを確認しましょう わんくま同盟 名古屋勉強会 #20
- 5. 仕様化テストを書きましょう わんくま同盟 名古屋勉強会 #20
- 6. 仕様が提示されるところから私たちの仕事が始 まることが多いと思います。 (TDDBC や今回のワークショップではお題) 私たちが最初にすることは、仕様を動作可能な プログラム言語で表現することです。 わんくま同盟 名古屋勉強会 #20
- 7. 仕様化テストを書きましょう • 仕様をテストケースにする • テスト設計の観点でテストケースを追加する わんくま同盟 名古屋勉強会 #20
- 8. 仕様をテストケースにする 仕様は、お客様が理解できなければいけないの で自然言語や図を使って表現されます 私たちプログラマーは、この仕様をプログラミ ング言語で表現します。 何故でしょうか？ わんくま同盟 名古屋勉強会 #20
- 9. 仕様をテストケースにする 実行して、その振る舞いを検証することが できるからです。 わんくま同盟 名古屋勉強会 #20
- 10. 仕様をテストケースにする 仕様を、プログラミング言語で忠実に表現するこ とに注力しましょう。 あまりにも汚かったり冗長になってしまう場合は 、組み込み DSL などの技法を適用しましょう。 大事なのは、後から読んでも理解しやすいテ ストケースを作成することです。 わんくま同盟 名古屋勉強会 #20
- 11. テスト設計の観点 テストの設計という観点があります。 仕様から必要なテストを導き出すための大切な 観点です。 同値分割、境界値分析、ドメイン分析などがよく 使われると思います。 テスト設計の観点から導かれるテストケー スを書きましょう。 わんくま同盟 名古屋勉強会 #20
- 13. 仕様に対する理解は十分でしょうか？ (まだ何のコードも書いていません！) 仕様に対する理解が曖昧な場合、分かっている 範囲で先に進んでまた戻ってくればよいと思 います。 私は、それができるのが TDD の利点だと考え ています わんくま同盟 名古屋勉強会 #20
- 14. 設計しましょう わんくま同盟 名古屋勉強会 #20
- 15. 仕様をプログラミング言語によってテストケース という形にすることができました。 コンパイルすら通らないかもしれません。 それも含めて、次にやらなければならないこと を洗い出しましょう。 わんくま同盟 名古屋勉強会 #20
- 16. 設計しましょう • タスクリストを書き出す • タスクリストをテストにする • 不安をテストにする わんくま同盟 名古屋勉強会 #20
- 17. タスクリストを書き出す 今、私たちが相手をしているのは、1 つの仕様 (という名のテストケース) です。 このテストケースが成功するために必要な事柄 を思い付く限り洗い出しましょう。 「○○クラスを作る」 「△△メソッドを作る」 「☆☆関数を作る」… わんくま同盟 名古屋勉強会 #20
- 18. タスクリストを書き出す 大事なのは、1 つのタスクが完了することで、 1 つのモノ・コトが出来あがっていることです 。 問題を分割するという行為を自然に行えるよう になりましょう。 詳細は 「テストリストの見つけ方」 (@shuji_w6e さん) を参考にしてください。 わんくま同盟 名古屋勉強会 #20
- 19. タスクリストをテストケースにする タスクの中には「●●というメソッドを作る」とい うものがあるかもしれません。 オブジェクト指向設計において、メソッドは 1 つの設計要素です。 入力と出力が明らかになっているなら、それ を確認するためのテストケースを書きましょう。 わんくま同盟 名古屋勉強会 #20
- 20. 不安をテストにする タスクの中には「■パターンで○クラスを作る」 というものがあるかもしれません。 自分がよく使っているデザインパターンであれ ば、抑えるべきポイントは明らかかもしれませ ん。 しかし、あまり使わないデザインパターン (Flighweight パターンとか) ではどうでしょう か？ わんくま同盟 名古屋勉強会 #20
- 21. 不安をテストにする 私なら、ちゃんと書けているか自信がありません (=不安)。 考えたとおりの振る舞いになっているか どうかを確認するためのテストケースを書くこ とでしょう。 わんくま同盟 名古屋勉強会 #20
- 22. リファクタリングしましょう わんくま同盟 名古屋勉強会 #20
- 23. 設計 (実装) ができてきました。 仕様化テストを通すための必要最低限の実 装です。 ハードコーディングされた定数、if 文、while 文、などなど気になるところもあるでしょう。 わんくま同盟 名古屋勉強会 #20
- 24. これらをきれいにして、保守しやすいコードにす る営みがリファクタリングです。 リファタリングの最重要事項は、最終的に仕様 化テストが成功することを維持しつつ、リファク タリングを行う前よりもコードをきれいにするこ とです。 わんくま同盟 名古屋勉強会 #20
- 25. リファクタリングしましょう • 順を追って進める • 新たなインターフェース境界ができたら わんくま同盟 名古屋勉強会 #20
- 26. 順を追って進める ここに至るまでのリズムはアレグロな感じだと思 うので、リズムを変えましょう。 リファクタリングは、一歩一歩、順番を守って進め ることが大事です。 その都度、テストを実行して、期待した通りの結 果になることを確認しながら進めていきましょ う。 わんくま同盟 名古屋勉強会 #20
- 27. 新たなインターフェース境界ができたら リファクタリングをすると、新しいインターフェース やクラスが登場することがあります。 もし、インターフェースの境界が増えたのならば、 そこに関するテストケースも追加しましょう。 わんくま同盟 名古屋勉強会 #20
- 28. 新たなインターフェース境界ができたら インターフェースの境界は、拡張ポイントとして 必要になるから発生したのだと考えられます。 拡張ポイントについて後からコードを追加してい く人にとって、そのテストケースはよいサンプル コードとなるでしょう。 わんくま同盟 名古屋勉強会 #20
- 29. テストもリファクタリングし ましょう わんくま同盟 名古屋勉強会 #20
- 30. 仕様について設計(実装)が終わりました。 目の前には、設計段階で洗い出したタスクリスト や、不安に対するテストが並んでいます。 これらを放置しておくと、あっという間にゴミのよ うになってしまいます。 わんくま同盟 名古屋勉強会 #20
- 31. テストもリファクタリングしましょう • 重複したテスト • 同じフィクスチャーを使っているテスト わんくま同盟 名古屋勉強会 #20
- 32. 重複したテスト 仕様化テストで動作の検証が済んでいるコード については、設計時に作成したテストケースは 、ざっくりと削除してもよいかもしれません。 設計レベルでの変更があるかもしれない、という 意味で、インターフェース境界のテストは残し ておいたほうがよいでしょう。 わんくま同盟 名古屋勉強会 #20
- 33. 同じフィクスチャーを使っているテスト 同じフィクスチャーを使っているテスト は、Shared Fixture パターンにリファクタリン グするとよいでしょう。 詳細は 「xUnit Test Patterns」 (xUTP読書会Wiki) を参照してください。 わんくま同盟 名古屋勉強会 #20
- 34. テストが何を保証してい るか確認しましょう わんくま同盟 名古屋勉強会 #20
- 35. 「コードカバレッジは 100% です」これが何を意 味するのか私には分かりません。 テストで全てのパスを通過していれば、問題は 無いのでしょうか？ TDD で書いたテストは、「仕様についての理 解度」、「設計に対する自信」を保証している のです。 わんくま同盟 名古屋勉強会 #20
- 36. テストが何を保証しているか確認しましょう • テストカバレッジ わんくま同盟 名古屋勉強会 #20
- 37. テストカバレッジ 大事なのは、システム (コンポーネント) の振る 舞いの定義域のうち、どれだけの領域がテス トされているかを表す指標値です。 私はこれがテストカバレッジの定義だと思ってい るのですが、具体的な定義については知らな いので、勉強しないといけないなと考えていま す。 わんくま同盟 名古屋勉強会 #20
- 38. 最終的に残るものを確認 しましょう わんくま同盟 名古屋勉強会 #20
- 39. 最終的に残るものを確認しましょう 回帰テストのために残すべきテストにはどういっ たものがあるでしょうか。 テストケースのリファクタリングによって数は減 らされたとはいえ、これだけは 残しておきたいというものを挙げるとすると、次 の 3 種類が残ります。 わんくま同盟 名古屋勉強会 #20
- 40. 最終的に残るものを確認しましょう 1. 仕様化テスト 2. インターフェース境界のテスト 3. テスト設計の観点で追加されたテスト 特に 3 のテストについては、品質保証 (Quality Assuarance) にも関連すると思うのですが、 私はまだそこまでカバーできる知識が足りな いので、識者の方に教えていただきたい分 野です。 わんくま同盟 名古屋勉強会 #20
- 41. 以上です。 ご清聴ありがとうございました。 わんくま同盟 名古屋勉強会 #20
- 42. 宣伝 • 第6回 Growing Object-Oriented Software, Guided by Tests読書会( #goos_jp ) – http://atnd.org/events/23826 – #goos_jp • ぺけま 0004 号 – http://devtesting.jp/pekema/ – #xutp • インフラ&アプリエンジニア合同合宿 – https://sites.google.com/site/infrapp2012/ – #infrapp2012 わんくま同盟 名古屋勉強会 #20