TDD を自分の道具にしよう

1,369 views

Published on

わんくま同盟 名古屋勉強会#20(1/14)のLT資料です。
http://www.wankuma.com/seminar/20120114nagoya20/

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,369
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

TDD を自分の道具にしよう

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

×