#はじめに
ちょうど去年の今頃からバックエンド開発でTDDを始めました。
自分が今のプロジェクトにjoinした時は、1/3くらいテストが書かれているという状態だったと思います。導入から1年ほど経過して、メリットやデメリット、コツ、そしてなぜ僕がTDDにハマったかも分析しました。
詳細な方法論とか書いてないのでご注意を。
#学習方法
まず、TDDを実践するにあたり参考にしたのは、以下のリンクにあるKentBeckのTDD本と、日本でTDDといえば和田さんのライブコーディングです。
この二つを読んで、見ておけば大体問題ないと思います！
特に和田さんのライブコーディングは、疑問が生じたりするたびに見直しました。
#導入のコツ(個人)
- 最初にテストを書く
とにかく、実装する前ににテストを書いてみること。これにつきます。
最初はすぐにテストをすっ飛ばしてコーディングを開始しちゃったりしますが、グッと堪えてテストを最初に書きましょう。
普段からテストを書き慣れていない方は一苦労かと思いますが、テスト技能の向上のためと思ってください。1~2週間続けていると、慣れてきてそんなに苦じゃ無くなってきます。
- 完璧主義にならない
TDDでは最初からテストを完璧に書こうとする必要はありません。テストを完璧に書くのは本実装を完璧に書くのと同じくらい難しいです。まずは、1番簡単で基礎的なテスト（eg. stringの値が戻ってくること等)から書き始めましょう。
#導入のコツ(チーム)
- まずは自分が始める
チームにTDDを導入するのは個人でやるより、数倍難しいです。なぜなら、ほとんどのプログラマはテストを書くのが好きではないからです。まずやるべきは、自らがTDDを実践することです。実践してもない人の言うことほど信用ならないものはありません。
「あれ、なんかあいつ、最近テストちゃんと書いてるな...」と同僚に思わせておきましょう。
そして、自分の中で十分知見が貯まったなと思ったら、ペアプロでもライブコーディングでも良いので、実際に見てもらいましょう。そこで、どれほどTDDが素晴らしいものかを嬉々として語ると、周りのあなたを見る目が変わります。
- テストを書かないとPRが通らないようにする
どのような方法でも良いですが、仕組みを作ってしまいましょう。レビューでいちいち「テスト書いてください」と言い続けるとTDD原理主義者のレッテルを貼られてしまいます。
(本当はTDDでなくてもテストは書こう)
- 既存のコードにバグがあったときもテストコードを追加する
既存のコードにバグが見つかった時は、すぐさま直すのではなく、まずは再現するテストコードを書きましょう。そうすると、なぜだか知りませんが、やっぱりテストって大事やなと周りが思ってくれます。
まあ、本当にTDDしてるのか後からテストを書いているのかは、実際のところ分かりませんが、こんな感じで進めると良いと思います（適当）
#メリット・デメリット
##メリット
- 安心感
個人的には、TDDの1番のメリットはコーディング中に感じる安心感だと思っています。TDDでは、今自分が書いているコードがGreenなのかRedなのか常に把握することができます。これは、実装をしていて感じる不安を大きく取り除いてくれます。そして、もしGreenな状態に戻りたくなれば、いつでも戻ることができます。TDDを始めれば、きっとあなたも安らかな気持ちでコーディングできるでしょう。
- 仕様が明確になる
テストが書けるとは、機械が理解できるレベルに仕様が明確であることを意味します。
特にきちんとした仕様書がなく、ざっくりとした指示のもとコードを書くことの多いスタートアップのチームほど役に立ちます。また、後から誰かがjoinする際にも仕様書として利用することもできます。
- リファクタリングしやすい
テストの１番のメリットといえばリファクタリングです。テストがあるだけでリファクタリング意欲が湧いてくるというものです。(そうですよね？）
- 楽しい！
楽しいです。もしTDDが楽しくなければ、やらない方が良いでしょう。
その他にも書ききれませんが、テスト技能、設計技術の向上など様々なメリットがあります。
##デメリット
- 導入コスト
やはり１番のデメリットは導入コストなんじゃないかと思います。最初はなかなか面倒ですし、工数もかかります。誰かが率先してやらないとなかなかチームに根付くのは難しいです。導入したからと言って目に見える成果があるかと言われると難しいかもしれません。(ビジネスサイドから見て）
- テストにかかる工数
テストを書くということは、それだけ工数もかかります（実はTDDの方が実質的に工数がかからないという研究はある）。また、メンテナンスや実行時間もかかります。
- 仕様が変わるとテストも変わる
仕様がコロコロと変わる開発スタイルだと、その都度テストも変更する必要があり面倒です。
#TDDはなぜ楽しいか
最初の苦痛期間を除けば、TDDでの開発体験は非常に楽しいものです。（信じてくれないかもしれませんが）TDDはなぜ楽しい開発体験を提供できるでしょうか。
####スモールステップの原理
心理学では、あるタスクを行う際に、内容をできる限り小さく分割してから実行することをスモールステップと呼んでいます。スモールステップは、タスクを小さく分割することで、その複雑さに向かい合う心理的ハードルを下げます。さらに小さいステップを多く達成することで、報酬系を刺激しモチベーションを向上させるため、結果的に作業効率が上がると言われています。
これらは、まさにTDDにおいて実践されます。
人はあまりに複雑なタスクがあると、手をつけるのが億劫になるものです。しかし、TDDでまず最初に行うのは何も書いていないテストを通すことです！（なんと、小さなステップでしょうか！）
その後、1番簡単な仕様をRedにして、またGreenにしてを繰り返します。その度、実装者は小さな目標を達成したという快感を得ることができます。これが、楽しくて仕方がありません。まさしくテストに駆動されてると感じることでしょう！
1ヶ月もTDDを実践すれば、あなたの脳はTDDなしでは実装できなくなっているでしょう！
それでは、楽しいTDDライフを！