ここ数日、TDDするかどうかの判断基準とは何か考えていた。結局、TDDしたほうがコードが早く完成するのならTDDすべきだし、そうでないならTDDすべきでないという結論に落ち着いた。

ぼくの場合、TDDしないほうが、コードが早く完成する傾向にあると思う。神経質なので、一度テストを書き始めると、完璧なテストケースを作らないと気が済まなくなる。そして、完璧なテストケースとは何かを考え始め、わけが分からなくなってしまう。コードはいつまでも完成しない。

もちろん、完璧なテストケースは、TDDのテストとは別のものだ。それは知っている。ユニットテストを書く段階で、与えられた期間などのリソースを考慮し、必要十分なテストを書けばよいだけの話なのだ。

頭ではそう理解できているのだが、いざTDDしようと思うと、気持ちが完璧なテストケースのあれこれに傾いてしまう。やはり、TDDはぼくには向いていないのだ。

久々にTDDについて考えてみたのは、TDD Boot Camp(TDDBC) - TDDBC仙台03/課題を読んだからだった。

たとえば課題1は、TDDしなくても、ぼくは特に不安なく開発できる。ぼく以外にも、そういう人は多いだろう。

だが、課題1の適切なユニットテストとはどういうものかと考えると、これがなかなか難しい。ぼくが身につけたいのは、TDDのスキルより、限られたリソースの中で必要十分なユニットテストのテストケースを書くスキルだ。数をこなすしかないか。