スローテストとTDD

XP祭り関西2011で井芹さんのTDDの話を聞きながら、改めてTDDの奥深さを実感した。
そして、僕が常日頃感じているスローテストについても考えてみた。
以下メモ書き。

【元ネタ】
DevLOVE-CI「たとえ世界が終ろうとも、僕はビルドをケイゾクする。」へ行ってきた - 虎塚

第3回 社外常駐で学んだアジャイル開発 | Think IT

[Agile][資料公開]DevLOVE Test Dayでお話しました #devlove | Ryuzee.com

DevLOVE Test Day に行ってきました #devlove - かおるんダイアリー (id:kaorun55)

JaSST2001参加 - a SE diary

スローテストとは「テスト・コードが多すぎて、すべて実行するのに時間がかかる」という問題。
TDDをちゃんとやっていくと、動くシステムのLOCよりもテストコードのLOCが10倍ぐらい増える。
すると、コミットする度にビルドすると時間がかかりすぎるし、夜間ビルドですら終わらなくなる。
ビルドが遅くなるということは、製品化する時間が長くなるということなので、Agileでないし、開発者もCIを実施してくれなくなる。

井芹さんにスローテストについて質問したら、DBにアクセスする部分をモック化したり、並行ビルドしてみたり、テスト環境を仮想化したり、色々やり方はありますよ、と聞いた。
僕はスローテストの問題は、まだまだ改善の余地があると思っている。

井芹さんの講演では、TDDでも可読性や保守性を高めるためにリファクタリングは必要であるという主張がずっと根底に流れていた。
テスト技法の解説書として、秋山さんの「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」や「はじめて学ぶソフトウェアのテスト技法」が紹介されているのには驚いた。
色々勉強されているなあという感想を持った。
TDDであろうとも、肝心のテストケースは既に知られている各種技法を使った方がテストの効率も生産性も上がる。

TDDでは普通とは異なるプログラミング技法がある点も技術者としては興味深い。
モックやリフレクション、メタ言語などがそれに当たるだろう。
「xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))」の本とその勉強会のログも紹介されていたので、調べてみたいと思う。

xUnit Test Patterns(xUTP)読書会 - FrontPage