Posted at

TDDの難しさ

人に伝えようとするとなかなか理解してもらえず、こんなのうまく行くはずがない、普通に開発した方が速い、といったご意見をいただきやすいのがTDD。

すごくいいやり方なのにも関わらずなんでこんなことが発生してしまうのか?

今までを振り返ると2つの理由があると思う。

1つ目は、そもそも仕様をコードに変換することに慣れていないという点。

一般的な請負開発では、上流とか下流とかいう言葉でソフトウェアの仕様と実装が分断され開発が行われる。これにより2つを行き来きするという活動が存在しないのだ。TDDはまさに仕様をテストコードとして最初に定義して進める開発手法だが、まずロジカルに仕様を捉えられないと、最初の時点で手が止まる。要は作りたいもののインプットとアウトプットを定義するだけなのだが、それに慣れてないのだ。ただそれは慣れの問題で、ある程度開発してきた人なら徐々に出来てくると実感としてある。

2つ目がなかなか厄介で、TDDで開発スピードが上がらない人が陥ってるところ。コーディングという作業のミスのしやすさ、そして覚えにくさを甘くみている点だ。

面白いことに初心者ほど甘くみている傾向がある。実際のTDDを行う際にどういうことをやりがちなのかというと、テストコードとプロダクトコードの行き来が少ない、もしくは行き来するまでが長いのだ。その結果、どこでミスしたかわからなくなるということが発生する。短い期間で行き来すればどこから失敗したかすぐわかるのに、そのタイミングを逃したために修正にとんでもない時間を使うのだ。

早く終わらせたいと思うが故に舐めてかかってしまうのだ。ここに関しては間違いなく「急がば回れ」だ。

この問題はテスト実行のやりやすさ、スピードも関係するかもしれない。

1+1は2であるという確証はあるかもしれないが1/2になると得意な言語以外はやってみないと、調べてみないとわからない人がほとんどではないだろうか?ならテストを書く必要があるのだ(流石に後から消すレベルのテストだけど)。

TDDを世に送り出したケントベック先生もハッカソンの時でさえなるべくTDDでやるのだとか。そんな人が急ぐ時でもやってるのに素人から少し毛が生えた程度の我々がどうしてテストも無しに開発が行えるのだろうか?

最後はなんか違う話な気がするが、この2点は今までの経験が邪魔をして自分は違う、自分はやれてると思いがちな部分だと思う。もちろん自分も含めてです。やれてない時多々あります!