TDD を自分の道具にしよう

わんくま同盟名古屋勉強会 #20

TDDを自分の道具にしよう

id:yujiorama

@yujiorama


自己紹介

• 千葉から来ました(たぶん初めて?)

• n次請けシステム開発屋

• 技術リードみたいなことをしたり、PLみたいなことをしてます

• Cが好きです。C++はもっと好きです。

• (一番好きなのはRubyです)


私たちの開発の進め方を変えてみませんか？


アジェンダ

• 仕様化テストを書きましょう

• 設計しましょう

• リファクタリングをしましょう

• テストもリファクタリングしましょう

• テストが何を保証しているのか思い出しましょう

• 最終的に残るものを確認しましょう


仕様化テストを書きましょう


仕様が提示されるところから私たちの仕事が始まることが多いと思います。

(TDDBC や今回のワークショップではお題)

私たちが最初にすることは、仕様を動作可能なプログラム言語で表現することです。


仕様化テストを書きましょう

• 仕様をテストケースにする

• テスト設計の観点でテストケースを追加する


仕様をテストケースにする

仕様は、お客様が理解できなければいけないので自然言語や図を使って表現されます

私たちプログラマーは、この仕様をプログラミング言語で表現します。

何故でしょうか？



実行して、その振る舞いを検証することができるからです。



仕様を、プログラミング言語で忠実に表現することに注力しましょう。

あまりにも汚かったり冗長になってしまう場合は、組み込み DSL などの技法を適用しましょう。

大事なのは、後から読んでも理解しやすいテストケースを作成することです。


テスト設計の観点

テストの設計という観点があります。

仕様から必要なテストを導き出すための大切な観点です。

同値分割、境界値分析、ドメイン分析などがよく使われると思います。

テスト設計の観点から導かれるテストケースを書きましょう。


ところで


仕様に対する理解は十分でしょうか？ (まだ何のコードも書いていません！)

仕様に対する理解が曖昧な場合、分かっている

範囲で先に進んでまた戻ってくればよいと思います。

私は、それができるのが TDD の利点だと考えています


設計しましょう


仕様をプログラミング言語によってテストケースという形にすることができました。

コンパイルすら通らないかもしれません。

それも含めて、次にやらなければならないことを洗い出しましょう。


設計しましょう

• タスクリストを書き出す

• タスクリストをテストにする

• 不安をテストにする


タスクリストを書き出す

今、私たちが相手をしているのは、1 つの仕様 (という名のテストケース) です。

このテストケースが成功するために必要な事柄を思い付く限り洗い出しましょう。

「○○クラスを作る」

「△△メソッドを作る」

「☆☆関数を作る」…


タスクリストを書き出す

大事なのは、1 つのタスクが完了することで、1 つのモノ・コトが出来あがっていることです

。

問題を分割するという行為を自然に行えるようになりましょう。

詳細は

「テストリストの見つけ方」

(@shuji_w6e さん)

を参考にしてください。

http://www.slideshare.net/shuji_w6e/ss-10035519

http://twitter.com/


タスクリストをテストケースにする

タスクの中には「●●というメソッドを作る」というものがあるかもしれません。

オブジェクト指向設計において、メソッドは 1 つの設計要素です。

入力と出力が明らかになっているなら、それを確認するためのテストケースを書きましょう。


不安をテストにする

タスクの中には「■パターンで○クラスを作る」というものがあるかもしれません。

自分がよく使っているデザインパターンであれば、抑えるべきポイントは明らかかもしれませ

ん。

しかし、あまり使わないデザインパターン (Flighweight パターンとか) ではどうでしょう

か？


不安をテストにする

私なら、ちゃんと書けているか自信がありません(=不安)。

考えたとおりの振る舞いになっているかどうかを確認するためのテストケースを書くこ

とでしょう。


リファクタリングしましょう


設計 (実装) ができてきました。

仕様化テストを通すための必要最低限の実装です。

ハードコーディングされた定数、if 文、while 文、などなど気になるところもあるでしょう。


これらをきれいにして、保守しやすいコードにする営みがリファクタリングです。

リファタリングの最重要事項は、最終的に仕様化テストが成功することを維持しつつ、リファクタリングを行う前よりもコードをきれいにするこ

とです。


リファクタリングしましょう

• 順を追って進める

• 新たなインターフェース境界ができたら


順を追って進める

ここに至るまでのリズムはアレグロな感じだと思うので、リズムを変えましょう。

リファクタリングは、一歩一歩、順番を守って進めることが大事です。

その都度、テストを実行して、期待した通りの結果になることを確認しながら進めていきましょ

う。


新たなインターフェース境界ができたら

リファクタリングをすると、新しいインターフェースやクラスが登場することがあります。

もし、インターフェースの境界が増えたのならば、そこに関するテストケースも追加しましょう。


新たなインターフェース境界ができたら

インターフェースの境界は、拡張ポイントとして必要になるから発生したのだと考えられます。

拡張ポイントについて後からコードを追加していく人にとって、そのテストケースはよいサンプル

コードとなるでしょう。


テストもリファクタリングしましょう


仕様について設計(実装)が終わりました。

目の前には、設計段階で洗い出したタスクリストや、不安に対するテストが並んでいます。

これらを放置しておくと、あっという間にゴミのようになってしまいます。


テストもリファクタリングしましょう

• 重複したテスト

• 同じフィクスチャーを使っているテスト


重複したテスト

仕様化テストで動作の検証が済んでいるコードについては、設計時に作成したテストケースは

、ざっくりと削除してもよいかもしれません。

設計レベルでの変更があるかもしれない、という意味で、インターフェース境界のテストは残し

ておいたほうがよいでしょう。


同じフィクスチャーを使っているテスト

同じフィクスチャーを使っているテストは、Shared Fixture パターンにリファクタリン

グするとよいでしょう。

詳細は

「xUnit Test Patterns」

(xUTP読書会Wiki)

を参照してください。

http://xunitpatterns.com/

http://www.fieldnotes.jp/xutp/


テストが何を保証しているか確認しましょう


「コードカバレッジは 100% です」これが何を意味するのか私には分かりません。

テストで全てのパスを通過していれば、問題は無いのでしょうか？

TDD で書いたテストは、「仕様についての理解度」、「設計に対する自信」を保証している

のです。


テストが何を保証しているか確認しましょう

• テストカバレッジ


テストカバレッジ

大事なのは、システム (コンポーネント) の振る舞いの定義域のうち、どれだけの領域がテストされているかを表す指標値です。

私はこれがテストカバレッジの定義だと思っているのですが、具体的な定義については知らないので、勉強しないといけないなと考えています。


最終的に残るものを確認しましょう



回帰テストのために残すべきテストにはどういったものがあるでしょうか。

テストケースのリファクタリングによって数は減らされたとはいえ、これだけは

残しておきたいというものを挙げるとすると、次の 3 種類が残ります。



1. 仕様化テスト

2. インターフェース境界のテスト

3. テスト設計の観点で追加されたテスト

特に 3 のテストについては、品質保証 (Quality Assuarance) にも関連すると思うのですが、私はまだそこまでカバーできる知識が足りないので、識者の方に教えていただきたい分野です。


以上です。

ご清聴ありがとうございました。


宣伝

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

http://atnd.org/events/23826

http://devtesting.jp/pekema/

https://sites.google.com/site/infrapp2012/

Documents

TDD を自分の道具にしよう