ここ数日、TDDするかどうかの判断基準とは何か考えていた。結局、TDDしたほうがコードが早く完成するのならTDDすべきだし、そうでないならTDDすべきでないという結論に落ち着いた。
ぼくの場合、TDDしないほうが、コードが早く完成する傾向にあると思う。神経質なので、一度テストを書き始めると、完璧なテストケースを作らないと気が済まなくなる。そして、完璧なテストケースとは何かを考え始め、わけが分からなくなってしまう。コードはいつまでも完成しない。
もちろん、完璧なテストケースは、TDDのテストとは別のものだ。それは知っている。ユニットテストを書く段階で、与えられた期間などのリソースを考慮し、必要十分なテストを書けばよいだけの話なのだ。
頭ではそう理解できているのだが、いざTDDしようと思うと、気持ちが完璧なテストケースのあれこれに傾いてしまう。やはり、TDDはぼくには向いていないのだ。
久々にTDDについて考えてみたのは、TDD Boot Camp(TDDBC) - TDDBC仙台03/課題を読んだからだった。
たとえば課題1は、TDDしなくても、ぼくは特に不安なく開発できる。ぼく以外にも、そういう人は多いだろう。
だが、課題1の適切なユニットテストとはどういうものかと考えると、これがなかなか難しい。ぼくが身につけたいのは、TDDのスキルより、限られたリソースの中で必要十分なユニットテストのテストケースを書くスキルだ。数をこなすしかないか。