TDDのやる気が出ないときに試したい簡単なヒント集

コードをテスト駆動で書きたいのに、なかなか手が動かない——そんな経験はありませんか?オブジェクトのインターフェースをどう設計すべきか確信が持てなかったり、晴れた夏の日に気を取られたり。「そもそもこのアイデアはテストできるのか?」と不安になったり、単純に今はテストを書きたくなくて先延ばしにしていたりすることもあるでしょう。では、TDDの気分になれないとき、どうすればTDDの恩恵を受けられるのでしょうか?

プロトタイピング――捨てる前提で一度作ってみる

「新しいシステムの概念や新しい技術を使う場合には、捨てるためのシステムを作らなければならない。どんなに優れた計画でも、最初から正しくやり遂げられるほど全能ではないからだ。だからこそ、一つは捨てるつもりで計画せよ。どうせ捨てることになるのだから。」
— フレッド・ブルックス

新しい機能の開発を始めるとき、最初のテストを書こうとすると足がすくむことがあります。APIの形をどうするか、どのパターンやプラクティスが最適か、全体をどう組み合わせるか——決めなければならないことが多すぎるのです。

そんなときに私が使っている立ち上がりの方法があります。そのひとつがプロトタイプを作ることです。

プロトタイプを書くときは、スケッチを描くつもりで取り組みましょう。ブレインストーミングのように自由に試してみてください。まだテストもTDDも不要です。代わりに、判断に迷っている部分をコードで探求します。いくつかのパターンを試して、設計中の機能にどれが合うか確かめましょう。アプリの脆い部分はどこか、何にもっと考えが必要か、何を根拠なく心配していたのかが見えてきます。

そして、それを捨てて作り直します。今度はTDDを使い、機能を最適に構築する方法について得た知識を活かしながらです。

何かを書いた後にうっかり git checkout -f を実行してしまい、お腹を蹴られたような気分になったことはありませんか?でも「これは作らなければならないものだ」と思い直してもう一度書いてみたら、結果的に最初よりずっと良いものになった——そんな経験はないでしょうか?プロトタイプの作り直しでも同じことが起こります。機能がどのような姿になり得るのかという確かなイメージができあがれば、TDDでの実装は格段にスムーズに進みます。

リバースTDD(逆順TDD)

作り方は分かっているのに、テストの書き方が先に思いつかない——そんな場面に出会ったことはありませんか?あるいはメソッドへの1行変更だけど微調整が必要そうで、実際の変更内容が固まる前にテストで固定したくない、といったケースもあるでしょう。

こうした状況で大きな助けになるシンプルな手順があります:

1. テストなしでコードを書きます。
2. そのコードに対するテストを書きます。必ずパスすることを確認してください。
3. 書いたコードをコメントアウトするか、変更したファイルを元に戻します。
4. テストを再実行します。必ず失敗することを確認してください。
5. コードをもう一度書き、テストを実行します。パスすることを確認します。
6. 新しいテストを活かしてコードをリファクタリングします。

私はこれをリバースTDD、あるいはグリーン→レッド→グリーン→リファクタリングと呼んでいます。TDDの「テスト駆動設計」の部分は得られませんが、コードが壊れたときにテストが失敗する様子を目にすることはできます。これは重要です。少なくとも一度も失敗しないテストは信用できません。

リバースTDDは、大きな設計を必要としない小さな変更に最も効果的です。バグ修正や、1行・1メソッド・1クラスに収まる変更などが典型です。とはいえ私自身、手を加えながら模索している小さな変更によく使っています。

ペアリングゲーム

近くに他の開発者がいるなら、Red-Green-Refactorのルーチンから抜け出すのに「ペアリングゲーム」がおすすめです。ルールは次のとおりです:

1. パートナーを見つけます。
2. あなたが失敗するテストを書きます。
3. パートナーが、そのテストを通すための最もシンプルなコードを書きます。
4. あなたが、そのコードで失敗する別のテストを書きます。
5. パートナーが、そのテストをパスするコードを書きます。
6. これを繰り返します……
7. テストがすべてグリーンになった時点で、新しくテストを書く代わりにリファクタリングを選んでも構いません。
8. リファクタリングの後は、テスト担当とコード担当の役割を交代します。

ちょっとした秘密を教えましょう。ボウリングのスコア計算機でペアリングゲームをしたことが、私がTDDを学んだ最初のきっかけでした。このゲームは、失敗するテストをもとにシンプルなコードを書く練習にも、そもそものテストを書く練習にもなります。二人の開発者が互いのコーディングスタイルや好みの技法について多くを学べるうえ、ほぼすぐにフロー状態に入れるので、終わったときには最高の気分になれるはずです。

コードを書くスピードは落ちるかもしれませんが、とても楽しく、素晴らしい学びの体験になります。

遊び心を忘れず、実験してみよう

TDDは教義である必要はありません。TDDの中核となる概念を遊ぶようにアレンジすると、思いがけず面白い場所にたどり着けることがあります。結果として、さらに良いコードが生まれるかもしれません。

だからこそ、実験してみてください。コードの書き方やTDDへの新しいアプローチを試し、それが自分にどんな感覚をもたらすか、どんなコードに行き着くかを観察しましょう。そして毎日の仕事の中で、楽しさとフローを見つけ直し続けてください。