うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

TDDを明確に定義する

TDD
").prependTo(".entry-content"); } //スクロールを滑らかにする $('.sectionList a').on("click", function() { $('html,body').animate({scrollTop: $(this.hash).offset().top}, 600); return false; }); });

ということで、TDDを定義します。

はじめに

TDDを定義し、それの基礎を明らかにし、リファレンスモデルを明にする。
そして、他の例も紹介してみます。

TDDとは何であるか

TDDとはソフトウェア開発者向けフレームワークです。
RED -> GREEN -> REFACTOR のスパイラルモデルが根幹にあります。
RED, GREEN, REFACTOR は開発者のアクティビティになります。
僕の理解ではプロセスの部分集合がフレームワークであるから、プロセスと呼ぶ事もできるけど、ここではフレームワークと表現します。


TDDは「開発者の意図を確認すること」「開発者が心地よいコードを書き始める事」を支援するフレームワークです。


TDDはフレームワークであるから、あくまでソフトウェア開発の支援が目的であり、それ以外は副次効果です。
直接的な効果として、TDDを導入する事によって「機能性」「保守性」が向上するという事例は少なくとも「開発者の意図」や「心地よいコード」というのがそれぞれに対応していることを意味しています。


TDD以外のフレームワーク(Webフレームワーク、バッチフレームワーク、アジャイル的なフレームワーク)においても言える事ですが、フレームワークを使用しても良くなる事も悪くなる事もあります。
MVC的なWebフレームワークの例で言えば、「Controllerにロジックを多量に書いていて、コードが汚くなりがちであったり、保守性が低くなっている。」という状況もあります。
Scrumの例で言えば、「バックログにはしているが、タイムボックスを守っていない。ただ忙しくなっただけである。」という状況もあります。


フレームワークで行える事が自由であればあるほど、原則から離れる事が容易になりがちです。秩序を保ちつつ、自由度が高い事がフレームワークとして優秀である事の特徴の1つであると考えています。


難しいのは、TDDは開発者のためのフレームワークであり、静的な(コンピュータによって制御する)フレームワークではないということです。つまり、プログラミング言語で課されるようなものと違って秩序を保ちにくい点があげられます。


自由度を下げて秩序を保ったフレームワークを実装する事は比較的容易ですが、それを使いこなすのは、往々にして難しくなりがちです。


TDDの基礎

TDDを支えるものとして次の要素があります。
客観的で頻繁にも実施できる検査群、確認し易い検査結果群、RED,GREEN,REFACTORのライフサイクル。
これらによって、「開発者の意図を確認すること」「開発者が心地よいコードを書き始める事」という目的を達成します。


客観的で頻繁にも実施できる検査群は、現実的には自動テストとして実現されることが多いのですが、それはあまりにも応用例すぎるので、あまり深くはつっこみません。
客観的というのは「誰が確認しても同一」、頻繁にというのは「1分周期くらいで」くらいの意味です。


確認し易い検査結果群は、検査群のどれくらいが成功し、失敗しているか、実行にどれくらいの時間がかかったかを5秒くらいで読み取れることを指しています。


RED, GREEN, REFACTOR の各アクティビティの定義は次の通り。
RED : 開発者の意図が実現されていないことを明確にする
GREEN : 開発者の意図が実現されていることを明確にする
REFACTOR : GREENを維持しながら心地よいコードを書き続けられるようにする



他にテストファースト、自動化されたテスト、リッチなリファクタリング環境、といったものを基礎要素として追加したTDDも存在します。


Kent BeckのTDD By Exampleでは「自動化されたテスト」による検査がTDDの基礎としてあげられていますし、リファクタリングについてはSmalltalkにその起源をさかのぼる事になります。


ただ、ここで定義するTDDにはそれらは基礎としては含みません。例えばTDD By Exampleで出てくるTDDの定義はKentBeckによるTDDの基礎論です。

TDDのリファレンスモデル

Kent BeckのTDD By Example による例がやはりリファレンスモデルだと考えています。


参照しにくい情報で申し訳ありませんが、@さんのTDD講演動画もやはり良いと思います。
「RED, GREEN, REFACTORというアクティビティ」と「コードの状態」を対応づけた黄金の回転は理解しやすいですね。


(これが一番いいのかわからないけれど、これしかちょっと見当たらなかった)

注意してほしいのは、上記のTDDの基礎を実装しているリファレンスモデルであって、ソフトウェアテストや設計などについては、副次的であったりしますし、少なくとも僕はソフトウェアテストという点においては同意出来ない点があります。
あくまで、TDDというフレームワークとしてのリファレンスモデルです。

テスト駆動開発入門

テスト駆動開発入門

TDDの他の実装例

日本人にとって、アクセスしやすく分かり易い例としてはやはりUncle Bob(Robert C Martin)によるTDDです。


彼のTDDは「何か変更を加えるなら必ずテストファーストすべきである」と強く主張するものです。ある程度TDDに挑戦した人にとっては難しいと感じると思いますが、彼は「辛いときにはグリーンバンドを見てプロであること思い出す」そうです。ストイックですね。
これは「自由度を下げる事で秩序をもたらす」ことの良い例だと思います。


詳細を知りたい方はCleanCode, CleanCoderといった書籍を買ってみるとよいと思います。


Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道


他にも #TDDAdventJP として2011冬にリレー連載されたTDDのブログ達はその実装例を示しています。
「printでも確認できているからTDD」という方もいらっしゃれば、「カバレッジを導入する」という方もいらっしゃいます。

TDD Advent Calendar jp: 2011 | Gihyo Digital Publishing



TDD他について気になっている方は次のリンクにアクセスしていろいろ見てみるといいでしょう。
【devtesting.jp】http://devtesting.jp/



応用を多分に含んでいますが、世界的名著であるGOOSの和訳である、実践テスト駆動開発。
GOOSは原著を読んでいるので書評ブログもそのうち書きます。

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)


まとめ

TDDはフレームワークなので、ひどいTDDをすることも、良いTDDをすることもできる。
良いTDDをするための制約を増やす事もできるが、リスクがある。
Webフレームワークの導入と同様に、導入するには多少のコストがあり、修練も必要であるが、メリットが大きいことや、個人で導入することが可能であることから多くの成功体験が語られる傾向がある領域である。
誰かがTDDのある部分を非難しているときは「Railsのここがいけていない」くらいに考えるのがよくて「でもSpringならこう解決する」って言う。Webフレームワークでは言えるのにTDDでそれが出来ないのは成長を妨げていないだろうか。
テスティングフレームワークはTDDというフレームワーク上で利用するライブラリです。なので、自分で定義したTDDフレームワークと相性の良いテスティングフレームワークを選択することが重要です。これはTDDの応用ですね。



蛇足

明にTDDについて語ってはいないのですが、個人的には「アジャイルソフトウェア開発の奥義」にでてくるペアプロの風景を綴った部分が好きです。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技