TDD を自分の道具にしよう

TDDを自分の道具にしよう id:yujiorama @yujiorama わんくま同盟名古屋勉強会 #20

自己紹介• 千葉から来ました(たぶん初めて?)• n次請けシステム開発屋• 技術リードみたいなことをしたり、PLみたいなことをしてます• Cが好きです。C++はもっと好きです。• (一番好きなのはRubyです) わんくま同盟名古屋勉強会 #20

私たちの開発の進め方を変えてみませんか？わんくま同盟名古屋勉強会 #20

アジェンダ• 仕様化テストを書きましょう• 設計しましょう• リファクタリングをしましょう• テストもリファクタリングしましょう• テストが何を保証しているのか思い出しましょう• 最終的に残るものを確認しましょうわんくま同盟名古屋勉強会 #20

仕様化テストを書きましょうわんくま同盟名古屋勉強会 #20

仕様が提示されるところから私たちの仕事が始まることが多いと思います。 (TDDBC や今回のワークショップではお題)私たちが最初にすることは、仕様を動作可能なプログラム言語で表現することです。わんくま同盟名古屋勉強会 #20

仕様化テストを書きましょう• 仕様をテストケースにする• テスト設計の観点でテストケースを追加するわんくま同盟名古屋勉強会 #20

仕様をテストケースにする仕様は、お客様が理解できなければいけないので自然言語や図を使って表現されます私たちプログラマーは、この仕様をプログラミング言語で表現します。何故でしょうか？わんくま同盟名古屋勉強会 #20

仕様をテストケースにする実行して、その振る舞いを検証することができるからです。わんくま同盟名古屋勉強会 #20

仕様をテストケースにする仕様を、プログラミング言語で忠実に表現することに注力しましょう。あまりにも汚かったり冗長になってしまう場合は、組み込み DSL などの技法を適用しましょう。大事なのは、後から読んでも理解しやすいテストケースを作成することです。わんくま同盟名古屋勉強会 #20

テスト設計の観点テストの設計という観点があります。仕様から必要なテストを導き出すための大切な観点です。同値分割、境界値分析、ドメイン分析などがよく使われると思います。テスト設計の観点から導かれるテストケースを書きましょう。わんくま同盟名古屋勉強会 #20

ところでわんくま同盟名古屋勉強会 #20

仕様に対する理解は十分でしょうか？ (まだ何のコードも書いていません！)仕様に対する理解が曖昧な場合、分かっている範囲で先に進んでまた戻ってくればよいと思います。私は、それができるのが TDD の利点だと考えていますわんくま同盟名古屋勉強会 #20

設計しましょうわんくま同盟名古屋勉強会 #20

仕様をプログラミング言語によってテストケースという形にすることができました。コンパイルすら通らないかもしれません。それも含めて、次にやらなければならないことを洗い出しましょう。わんくま同盟名古屋勉強会 #20

設計しましょう• タスクリストを書き出す• タスクリストをテストにする• 不安をテストにするわんくま同盟名古屋勉強会 #20

タスクリストを書き出す今、私たちが相手をしているのは、1 つの仕様 (という名のテストケース) です。このテストケースが成功するために必要な事柄を思い付く限り洗い出しましょう。「○○クラスを作る」「△△メソッドを作る」「☆☆関数を作る」… わんくま同盟名古屋勉強会 #20

タスクリストを書き出す大事なのは、1 つのタスクが完了することで、 1 つのモノ・コトが出来あがっていることです。問題を分割するという行為を自然に行えるようになりましょう。詳細は「テストリストの見つけ方」 (@shuji_w6e さん) を参考にしてください。わんくま同盟名古屋勉強会 #20

タスクリストをテストケースにするタスクの中には「●●というメソッドを作る」というものがあるかもしれません。オブジェクト指向設計において、メソッドは 1 つの設計要素です。入力と出力が明らかになっているなら、それを確認するためのテストケースを書きましょう。わんくま同盟名古屋勉強会 #20

不安をテストにするタスクの中には「■パターンで○クラスを作る」というものがあるかもしれません。自分がよく使っているデザインパターンであれば、抑えるべきポイントは明らかかもしれません。しかし、あまり使わないデザインパターン (Flighweight パターンとか) ではどうでしょうか？わんくま同盟名古屋勉強会 #20

不安をテストにする私なら、ちゃんと書けているか自信がありません (=不安)。考えたとおりの振る舞いになっているかどうかを確認するためのテストケースを書くことでしょう。わんくま同盟名古屋勉強会 #20

リファクタリングしましょうわんくま同盟名古屋勉強会 #20

設計 (実装) ができてきました。仕様化テストを通すための必要最低限の実装です。ハードコーディングされた定数、if 文、while文、などなど気になるところもあるでしょう。わんくま同盟名古屋勉強会 #20

これらをきれいにして、保守しやすいコードにする営みがリファクタリングです。リファタリングの最重要事項は、最終的に仕様化テストが成功することを維持しつつ、リファクタリングを行う前よりもコードをきれいにすることです。わんくま同盟名古屋勉強会 #20

リファクタリングしましょう• 順を追って進める• 新たなインターフェース境界ができたらわんくま同盟名古屋勉強会 #20

順を追って進めるここに至るまでのリズムはアレグロな感じだと思うので、リズムを変えましょう。リファクタリングは、一歩一歩、順番を守って進めることが大事です。その都度、テストを実行して、期待した通りの結果になることを確認しながら進めていきましょう。わんくま同盟名古屋勉強会 #20

新たなインターフェース境界ができたらリファクタリングをすると、新しいインターフェースやクラスが登場することがあります。もし、インターフェースの境界が増えたのならば、そこに関するテストケースも追加しましょう。わんくま同盟名古屋勉強会 #20

新たなインターフェース境界ができたらインターフェースの境界は、拡張ポイントとして必要になるから発生したのだと考えられます。拡張ポイントについて後からコードを追加していく人にとって、そのテストケースはよいサンプルコードとなるでしょう。わんくま同盟名古屋勉強会 #20

テストもリファクタリングしましょうわんくま同盟名古屋勉強会 #20

仕様について設計(実装)が終わりました。目の前には、設計段階で洗い出したタスクリストや、不安に対するテストが並んでいます。これらを放置しておくと、あっという間にゴミのようになってしまいます。わんくま同盟名古屋勉強会 #20

テストもリファクタリングしましょう• 重複したテスト• 同じフィクスチャーを使っているテストわんくま同盟名古屋勉強会 #20

重複したテスト仕様化テストで動作の検証が済んでいるコードについては、設計時に作成したテストケースは、ざっくりと削除してもよいかもしれません。設計レベルでの変更があるかもしれない、という意味で、インターフェース境界のテストは残しておいたほうがよいでしょう。わんくま同盟名古屋勉強会 #20

同じフィクスチャーを使っているテスト同じフィクスチャーを使っているテストは、Shared Fixture パターンにリファクタリングするとよいでしょう。詳細は「xUnit Test Patterns」 (xUTP読書会Wiki) を参照してください。わんくま同盟名古屋勉強会 #20

テストが何を保証しているか確認しましょうわんくま同盟名古屋勉強会 #20

「コードカバレッジは 100% です」これが何を意味するのか私には分かりません。テストで全てのパスを通過していれば、問題は無いのでしょうか？ TDD で書いたテストは、「仕様についての理解度」、「設計に対する自信」を保証しているのです。わんくま同盟名古屋勉強会 #20

テストが何を保証しているか確認しましょう• テストカバレッジわんくま同盟名古屋勉強会 #20

テストカバレッジ大事なのは、システム (コンポーネント) の振る舞いの定義域のうち、どれだけの領域がテストされているかを表す指標値です。私はこれがテストカバレッジの定義だと思っているのですが、具体的な定義については知らないので、勉強しないといけないなと考えています。わんくま同盟名古屋勉強会 #20

最終的に残るものを確認しましょうわんくま同盟名古屋勉強会 #20

最終的に残るものを確認しましょう回帰テストのために残すべきテストにはどういったものがあるでしょうか。テストケースのリファクタリングによって数は減らされたとはいえ、これだけは残しておきたいというものを挙げるとすると、次の 3 種類が残ります。わんくま同盟名古屋勉強会 #20

最終的に残るものを確認しましょう1. 仕様化テスト2. インターフェース境界のテスト3. テスト設計の観点で追加されたテスト特に 3 のテストについては、品質保証 (Quality Assuarance) にも関連すると思うのですが、私はまだそこまでカバーできる知識が足りないので、識者の方に教えていただきたい分野です。わんくま同盟名古屋勉強会 #20

以上です。ご清聴ありがとうございました。わんくま同盟名古屋勉強会 #20

宣伝• 第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

TDD を自分の道具にしよう

by Yuji Okazawa on Jan 14, 2012

Accessibility

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

TDD を自分の道具にしよう — Presentation Transcript