私が考えるTDD 〜TDDは天才にしかできないのか〜

TDD Advent Calendarに参加していないのに書くのも微妙なのですが、今回はTDDについてです。

TDD Advent Calendarの記事はかなりハイスペックな内容になっています。今回の私の記事はそれらには到底及ばないと思いますが、私の考えるTDDを書いて行こうと思います。

そもそもTDDとは

『TDDとはアジャイル方法論のエクストリーム・プログラミング（XP）のプラクティスの1つです。』

と言う話を聞きますがXPについてWebで調べてみると、「テスト駆動開発(TDD)」と書かれている場合と、「テストファースト」としか書かれていない場合の2種類の場合が存在します。
おそらく元々、「(Unit) Test First」と「Refactor」という2つのプラクティスがXPには存在していて、それがTDDというXP互換なプラクティスになって言ったのではないかと思います。

さらにTDDでは、細かい粒度で「テスト->最小限の実装->リファクタリング」を反復して行うという「インクリメンタル（漸進的）な開発」を行うということが求められています。

つまり「TDDは、XPのプラクティスのうちの、テストファースト, リファクタリング, 細かい反復を含んでいる。」わけです。

実際に、TDDがどのようなプロセスであるかと言うと

1.テストを書く。
テストはこれから書くコードに対しての要求をコードとして書くことになる。この際、プログラマはこれから書かれるコードに対しての要求を明確に理解することになる。

2.テストを実行する。
この時点ではテストされるコードがないため、失敗する。
このことでテスト（およびテスト環境）自体をテストし、もしコーディングで間違ったときにどのように失敗するか知ることができる。

3.テストをパスする最小限のコードを書く。
初めに最小限のコードから始めることで、細粒度な反復を行い、過度の抽象化を防ぐことができる。

4.テストにパスするより良いコードを書く（リファクタリング）
これにより安全に同じ動作をする、より良いコードを書くことができる。

となります。

TDDで何が得られるか

TDDでは何が得られるでしょうか。

私が知る限りの得られることを書いてみます。

• テストを最初に書くことで、プログラマは最初にコードに要求される振る舞い、テストがどのように行われるかを厳密に理解することになる
• テストファーストにより、すばやいフィードバックが得られる
• 最小限の実装から始めるため、過度な抽象化を防ぐことができる
• TDDのプロセスにより生成されたテストコードが（少なくとも）存在する
• 細かい反復の中でテストを行うため、失敗時に手戻りを抑えることができる
• テストにより安全に同じ動作をすることを保証されたより良いコードに書き変えること（リファクタリング）ができる

もっと得られることはあると思いますが、これらは特に大きいメリットではないでしょうか。

さらに

• プログラマがテストというものを知ることになる

と言う利点もあります。

TDDは天才にしかできないのか

さて、本題です。
「TDDは天才にしかできないのか」

私の答えは「ノー」です。

TDDと言うのはプロセスを除けば、今までの開発でプログラマがやってきたこととの違いは「テスト」だけです。つまりテストコードが書ければ、できないことはないはずなのです。

TDDでのテストはユニットテスティングフレームワークの使い方と、同値分割、境界値分析が分かっていればほとんどできることになります。
それができるというのを天才と呼ぶのであれば、テスターの方々は神ですね。いや、実際神のようにすごい人もいるんですが。

そして、TDDのプロセスはそれほど難しいことを要求してはいません。
いきなり「50段の跳び箱を飛べ」とは言っていないのです。
ただ単にその通りにやっていく感覚を身につけるだけです。

もっとも、どのようなことでも最初は難しいのは確かです。私自身いまだTDDを完全に習得したとは言えませんし、偉そうに言えるほどプログラミングのスキルや経験があるわけでもありません。
ですが、それでもTDDが「できない」わけではないのです。

本当にTDDができないわけ

とはいえ、できない理由もあります。

1. 圧倒的に書籍が少ないこと。
2. TDDを教えることができる人が少ないこと
3. やることとTDDが合致していないこと

です。

1つ目に関しては日本語では

テスト駆動開発入門

と言う本がありますが、さすがにこの本だけでTDDがマスターできるというのはかなりレベルが高い気がします。そして、洋書ではあるようですが、和書では他にはほとんどないのが現状のようです。

2つ目は、日本でTDDを実践でやっている人がそれほど多くはないことがあると思います。本だけでは分からないことを解消するためには経験者がいなければ難しいのですが、そういう人たちが多くはないという状況です。
TDDBCなど全国でTDDを実践的に経験できる勉強会もあっているので、そちらに参加するのが手っ取り早いのかもしれません。

3つ目は求められるセキュリティが非常に高い開発や、仕様がほとんど決まっていない中での開発などです。
特に仕様が固まりきれていない段階でのプロトタイプの開発などでは、TDD、特にテストファーストはかなり難しいです。
また単体テストがしにくいために、GUIや外部データなども難しいかもしれません。

で、何が言いたいか

• テストは知ってて本も読んだけれど、でもTDDをどうすればいいかわからない人はTDDBCへ行ってみましょう。

• テストが分からない人は簡単にでもテストと自分の使っているプログラミング言語のテスティングフレームワークについて勉強してみましょう。

• コードがTDD無しでもきっちり書けて、TDDが気に食わない人は無理してやらないようにしましょう。身体的にも精神的にも健康第一です。