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

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

12. ところで
わんくま同盟 名古屋勉強会 #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