「エンジニアの人生=エンジニアライフ」に役立つ本を紹介します。

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

»
Manual_2 実践テスト駆動開発

Steve Freeman、Nat Pryce(著)
和智右桂、高木正弘 (翻訳)
翔泳社
2012年9月

ISBN-10: 4798124583
ISBN-13: 978-4798124582
4,410 円(税込)

■「実践テスト駆動開発」ーー諸君、これがTDDの実践だ!

 TDDは広まりつつある。しかし……。

 アジャイル開発を行う上で、必須といってもいいプラクティスの1つに「テスト駆動開発・TDD」がある。このTDDのバイブルである「テスト駆動開発入門」をKent Beck氏が世に出してから、10年が経った。その間に、欧米では、すでにアジャイルがメインストリームとなった。日本でも、多くの諸先輩方が実践を続けていくなかで、ようやく広まってきたところだ。TDDを学ぶイベント「TDD Boot Camp」も、毎回キャンセル待ちの人が数多く出る人気イベントとなっている。

 日本でも、TDDに対する裾野はだいぶ広がっているのだろう。しかし、いざ実際の仕事でTDDをやろうとすると、いくつもの壁にぶち当たる。イベント駆動型クライアントアプリケーションの場合、データベースが絡む場合、マルチスレッドの場合、サードパーティのコンポーネントを使う場合。あまりに壁が大きいため、挫折してしまった人も少なからずいるだろう。かくいう私も、こうした壁を前にして、心が折れた経験を持っている。

 そうした、悩めるTDDerに向けて書かれた本が、本書「実践テスト駆動開発」である。本書は、世界中のアジャイリストが10年の歳月をかけて積み上げてきた、“TDDを行う上での壁”に立ち向かう術を教えてくれる、テスト駆動開発の奥義書である。

■そもそもTDDとは何か

 Wikipediaによると、

 プログラムに必要な各機能について、最初にテストを書き(これをテストファーストという)、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。

とある。

 では、TDDをすることで、どういった恩恵があるのだろうか。本書では

 システムを開発する際には、TDDを採用することで、実装(「正しく動くか?」)と設計(「適切な構造になっているか」)両方の質についてのフィードバックが得られる。テストを先に書いて開発することで、投入した労力による恩恵が二重に得られるのだ。

とある。つまるところ、TDDをすることは、設計と実装を小さなスケールで絶え間なく繰り返すことで、正しいソフトウェアを作っていくことに他ならない。

■立ちはだかる壁を内包したアプリケーションを、TDDで育てていく

 では、実際にTDDはどういった形で進めていくのだろうか。本書のサンプル「オークションスナイパー」というサンプルアプリケーションの開発内容を一部紹介していく。

 まず行うのが、アプリケーションの全体像を考えること。必要となるプロトコルや、状態遷移、扱う機能について洗い出す。いきなりテストコードを書くのではないのだ。何をしなければいけないのか。どういった技術基盤の下に行うのか。そうしたアプリケーションの設計を行う必要があるのだ。

 そうしてアプリケーションの設計をした後に行われるのが、「動くスケルトン」と呼ぶものを作ること。これはシステムで必要となるコンポーネントを網羅した形で一つの機能を、エンドツーエンドテストーーユーザーインターフェイスからサーバとの通信を経て、結果が出るまでーーとして成功するものとして構築したものである。

 「オークションスナイパー」システムでいうと、ユーザーインターフェイスやスナイパーコンポーネント、オークションサービスとの通信を網羅した形で一つの機能をTDDで実装するとしている。

 このとき、オークションサービスは実際のものを使わず、同じように動作させることのできる仮想サービスを用意して行う。

 いわば、アーキテクチャの検証である。考えたアーキテクチャが正しいかどうかを検証するのだ。こうしてアーキテクチャの検証を終えた「動くスケルトン」に一つずつ機能を追加していく。

 「オークションスナイパー」システムは、最初偽のオークションサービスとコネクションを行い、オークションの終了を見届けるだけの機能から作成を始めている。そこから一つづつ機能を追加していく形で、入札を行ったり、新しい商品を追加できるようにしていっているのだ。

 もちろん、テストコードを書き、それが全て成功するのを保つようにして追加していくのだ。このようにして、正しいソフトウェアを育てているのだ。

 実際のアプリケーションをTDDで開発していくのにここまでやる必要があるのかと、私は圧倒された。しかし、ここまでやるからこそ正しいソフトウェアを育てていけるのだろう。ウォーターフォール型開発で最後にテストを行なうことで、バグが吹き出して苦しい思いをする。それに比べれば、こちらの方が、開発は大変ではあるが、安心して開発ができるように思う。

■すべてのTDDの難問に対する解はここに

 この「オークションスナイパー」のサンプルには現れていない、TDDをする上で陥りやすい罠や立ちはだかる壁はまだ多くある。こうした難問に対しても、本書は解を示している。

 例えばデータベースを扱う際のTDDはどのようにして行えばいいのか。永続データの消去をテストの開始前に行うのだ。整合性制約があるので、テーブルから行を削除する順序を一つにまとめ、行うのがよいとしている。

 トランザクションを必要とする場合はどうすればいいか。トランザクション管理を行うオブジェクトを抽出し、そのなかでユニット・オブ・ワークパターンを用いればよいとしている。

 他にもマルチスレッドでのTDDや非同期処理でのTDDなど、「こういう場合のテストはどう書けばいいんだ……」という、TDDerの悩みに本書は応えてくれるだろう。

■TDDを学び、本書を携え実践しよう

 残念ながら、本書はこれからTDDを学ぼうとする人が読むには敷居が高いだろう。初めてTDDを学ぶならば、やはりKent Beck氏の「テスト駆動開発入門」を読み、実際にコードを打ち込んで、体験する必要があるだろう。もちろん、TDD Boot Campへ参加するのもいいだろう。

 そうやって、TDDを学んで実際に使い始めると「こういう場合どうすればいいんだ……」という場合が必ず訪れる。そのときこそ、本書はあなたの力になってくれるだろう。私もまた、本書を携えてTDDを実践していこうと思う。

『What a wonderful world』コラムニスト たのっち)

Comment(0)