今読んでる本 - 『テスト駆動開発入門』

2009/03/05

テスト関連の本をぼちぼち読もうと思っていて,まずは少しニアミス気味に TDD(Test Driven Development; テスト駆動開発)の本を読んでいます。昨日買いました。

Amazon のレビューには,「読みづらい」とかいった話があるんですけれど,これはたしかに読みづらい。でも,これは訳のせいというより,著者のナンセンスジョークや回りくどい比喩のせいなんだと思います。あたしゃ原書を読んでないんですけど,「こんなんどうやって訳すんだ」みたいな箇所があったんじゃないだろうか。ちなみに,著者のケントベック氏は,JUnit の開発者です。

もっとも本書の場合,著者のセンスがいまいちでも,ソースコードを追っていけば,TDD がどんなものなのかつかむことができると思います。著者が何度も繰り返すように,TDD のキモは以下の5点を繰り返すことだったりします。

  • 小さなテストを追加する。

  • すべてのテストを実行し失敗する。

  • 変更を行う。

  • テストを実行し成功する。

  • 重複を取り除くために、リファクタリングを行う。

本書の独特な波に乗るには,この点を実践的に踏まえている必要があるんじゃないかと思います。そうじゃないと,迷子になってしまう。だからこそ,何度も何度も繰り返しているんだろうけども。

TDD の話をすると,あたしゃこゆ手法は,割とみんながやってることなんじゃないかと思っていました。つまり,ゴールとなる小さなテストケースを成功させていくことで,徐々に大きなモジュールにしていくアプローチです。本書ほど洗練されてはいないけれども,本体のプロジェクトを作ったら,テストプロジェクトも普通作るよね,と。

つことで,本書の読みどころは,テストを成功させた後のリファクタリングにあるんだと思っていたりします。ま,それだったら,それ用の本を読めばいい話なんですけど。

一方で,ちと思ったんですけれど,TDD 周りの話の場合,「TDD は単体テストになるか」という話もあるんじゃないだろうか。もちろん,xUnit なんかを使っている向きにとって,TDD は unit test をしながら開発していくことといった認識だと思うわけで,多分それで間違っていないところもあるんだと思う。

ただ,あたしの場合,単体というと「徹底的にやるもの」といった認識があるもんで,余裕があったらいつまででもテストしていたりします。んなもんで,普段から異常系のテスト量が非常に多かったりする。作った後は,小姑のようにいじめ抜くという……。やなやつですね。これはつまるところ,徹底的にホワイトボックステストをするってなことなんですけれど,TDD のテストはどちらかというとブラックボックステストに近い。言いすぎなら,グレーボックステストか。

例えば TDD の場合,ゼロ除算のテストケースを作るべきか,とかいった話になると,「そこまでせんでいい」ということになるんだと思います。けど,普通,単体といったら限界値分析でゼロ除算になるケースをテストケースに入れるでしょ。正常系を作る上では不要なテストであっても,結合試験以降に起こりうる不具合に向けて,モジュールの堅牢性を高めておく(いぢめておく)ことは,普通するんだと思います。限度はあるけれども。こゆのに TDD は対応できるんだろうか。

TDD は雑誌の特集を読んだことがあるくらいで,あまりよく知らなかったんですけれど,本書はかなり詳しく TDD の手順を説明しています。確実でインクリメンタルな開発をお望みの向きには,ぜひともお勧め。

Site Navigation
SNS Accounts (@aian)

普段はここら辺に住んでいます.