TDDのフライホイールを回し始めるには？初心者のための実践ステップ

（筆者は今週、シカゴで開催されるRailsConfに参加しています。会場でお見かけの際は、ぜひ気軽に声をかけてください。お会いできるのを楽しみにしています。サイドバーの写真で年配の方が私です。）

読者からの質問：「TDD、どう始めればいい？」

ある読者から、記事へのコメント欄でテストに関する素晴らしい質問をいただきました。

「TDD（テスト駆動開発）のフライホイールを回さなければならないのは分かるのですが、TDD自体にあまり馴染みがありません。RSpecを使い始めるのに最適な方法はありますか？それとも、とにかく手を動かして試してみるしかないのでしょうか？」

そこで私は次のように答えました。

まずはminitestから始めるのもおすすめ

RSpecかminitestか、どちらかに決めていないのであれば、実はminitestの方が始めやすいかもしれません。minitestはより「メソッドとクラス」ベースのシンプルな作りなので、新しい構文を覚える負担がなく、TDDの学習と練習そのものに集中できます。

また、Railsにはテスト用語、アサーション、Railsでのテスト実行方法について解説した充実した公式ガイドがあるので、そちらも活用しましょう。

TDDを学ぶ最良の方法は「練習」——基本の7ステップ

TDDを身につける最良の方法は、とにかく練習することです。以下の手順に従ってください。

1. 必要なコードがすでに存在するものとして想定したテストを書く
2. テストを実行し、新しいテストが失敗することを確認する
3. テストを通すための最もシンプルなコードを書く。この段階では過度な抽象化やリファクタリングはしない
4. テストを実行し、新しいテストが成功することを確認する
5. 重複を取り除いたり、コードをより表現豊かにしたりするためにリファクタリングする
6. 再度テストを実行し、まだ成功していることを確認する
7. ステップ1に戻る

TDDを練習している間は、常に自分自身に問いかけてください。「今はどのステップにいるのか？」「ステップを飛ばしていないか？」「次はどのステップか？」——常にこれらのステップのいずれかにいるはずです。こうした自問が、正しい軌道に留まる助けになります。何か新しいことを学んでいる最中には、これが本当に重要です。「練習は恒久的な習慣を作る（Practice makes permanent）」のですから、間違ったやり方を練習して体に覚え込ませてしまうのは避けたいところです。

しかし同時に、「失敗してもいい」と自分に許可を出してください。あなたは学んでいる途中なのですから、まったく問題ありません。繰り返すうちに、きっとぐっと楽になりますよ。

見落とされがちなポイント：テストを書く「前」の計画

こちらもテストに関する書籍を執筆中のEric Steele氏から、私が見落としていた重要なポイントが挙げられました。

TDDで後回しにされがちなのが、ステップ1の前に必要となる計画の作業量です。

テストとは、アプリケーションの要件と、計画された実装が出会う場所です。テスト駆動開発は「アプリが何をすべきか」を把握していることに強く依存しており、さらにその「実現方法」についてもある程度のアイデアを持っていることを前提としています。

Railsを使い始めたばかりの頃は、まだ多くのことを知りません。求めている結果に近いものが得られるまで、実験的なコードを大量に書くことになるでしょう。学びが深まるにつれて、そうした試行錯誤は自然と減っていきます。だからこそTDDは「何を作るかを考える」ではなく「テストを書く」から始まるのだと思います。テストを書ける段階に達した頃には、すでに十分な経験を積んでいるはずなのです。

「テストを書く」の前に、以下のステップを追加することをお勧めします。

1. 要件をブレインストーミングし、正当性を検証し、取捨選択する。コーディングは極力避ける
2. それらの要件を満たすコードを計画・設計する
3. 未知の疑問に答えるためにコードを試しに書いてみるが、そのコードは脇に置いておく

私からのアドバイスは次の3つです。

• 構文よりも計画に集中する
• ツールは最小限に抑える（minitestとfixturesの組み合わせがとても役立つと感じました）
• 練習、練習、そして練習。

まとめ：続ければ必ず自然にできるようになる

何事もそうであるように、TDDを始めるには練習と、自分で軌道修正する力（あるいは、そばで修正してくれる人の存在）が必要です。いくつかの半ば厳格なステップに従い、今プロセスのどこにいるのかを意識し続けることができれば、TDDはすぐに完全に自然なものへと感じられるようになるでしょう。