テストのないアプリをTDDに移行するには？今から始められる段階的なステップ

せっかく作った自分のアプリ、ワクワクしているはずです。でも、ひとつだけ問題があります――テストが存在しないのです。本来ならテスト駆動開発（TDD）で書きたかったのに、どこから手をつければいいのかわからず、そのまま足止めされてしまった。さて、ここからどう進めばいいのでしょうか？テストゼロの状態から、TDDでアプリを開発できるようになるまで、どうやって橋渡しをすればいいのでしょうか？

まずは、すでにあるコードをテストする

目の前には、テストのない大量のコードがあるかもしれません。しかし、それは今この瞬間にテストを書けないという意味ではありません。まずは既存のコードに対してテストを書き、「コードが期待どおりに動いているか」を確認することから始めましょう。

これは厳密にはTDDではありません。しかし、既存コードへのテストは、TDDを「学ぶ」ための最高のトレーニングになります。

• エッジケースやエラー条件について考える練習になる

  あらゆる入力パターンを何年もかけてテストせずに済むようにするには、「コードがどこで壊れやすいか」を見極める思考力が必要です。たとえば、文字列を受け取るメソッドなら、シンボルを渡したらどうなるでしょうか？nil を渡したら？数値の割り算を行う関数なら、0による割り算は必ずテストすべきですが、1と2の両方を個別にテストする必要はおそらくないでしょう。

  テストを書き重ねていくと、メソッドがどの場所で壊れやすいかを事前に予測できるようになります。そして実際にTDDを始めたとき、このスキルこそが、エッジケースを強制的に検証する堅牢なテストを書く力になります。

• 構造の整ったテストの書き方を練習できる

  後からテストを書くスタイルでは、テストの構成パターンをいろいろと試せます。テスト対象のコードはすでに存在するため、テストそのものとその書き方に集中できるのです。優れたパターンをいくつか身につければ、頼れる実装コードがない状況でも、質の高いテストを書けるようになります。

• コードがテストしにくくなる原因を発見できる

  テストの経験を積むにつれて、システムの中で「特にテストが難しい部分」が感覚的にわかるようになります。そうした箇所に気づいたら、リファクタリングが必要な候補として明示しておきましょう。さらに嬉しいことに、最初からテストしやすいコードを書く癖が自然とついてきます。

  「テストしやすいコードとはどんな形か」がわかれば、その知識をもとにTDDでテストしやすいAPIを設計できるようになり、アプリ開発全体のスピードアップにつながります。

TDDへ段階的に移行する

後からテストを書く手法（test-after）は、TDDに必要なスキルを磨くのに役立ちます。とはいえ、最終的にはアプリの一部をTDDで開発したいものですよね。そんなとき、既存のコードに頼りながらTDDに慣れていくためのシンプルな方法があります。それは「回帰テスト」を書くことです。

回帰テストは、一度修正したバグを二度と壊さないための仕組みです。考え方はとてもシンプルです。バグの報告を受けたら、ブラウザ上でクリックしながら現象を再現する代わりに、次の手順を踏みます：

• 失敗するテストを書き、バグを再現する
• テストを実行し、本当に失敗することを確認する（バグがまだ存在している証拠）
• 最もシンプルな方法でバグを修正する
• テストを実行し、すべて成功することを確認する
• 必要であれば、修正内容をリファクタリングする

このプロセスは、ゼロから新しいシステムをTDDするよりもはるかにハードルが低いのです。すでに存在するコードへの変更をテストドライブするだけでいいからです。この繰り返しを通じて、TDDの本質である「Red, Green, Refactor」のサイクルが自然と体に染みつきます。そしてここから先の道のりは、テストゼロの状態からいきなりTDDに挑戦するよりも、はるかに短いものになるのです。

テストゼロからTDDへ

テストのないアプリは、決して悪い出発点ではありません。既存コードのテストを書く過程で、優れたTDDテストに必要な考え方の多くを吸収できます。test-afterは、まだ設計方法を想像できないAPIをいきなり想定する必要がない分、最初のうちはTDDよりも取り組みやすくなっています。そして、いざアプリにTDDを導入すると決めたときには、回帰テストを入り口にして無理なく移行できます。

だからこそ、思い描いているシステムをどうTDDすればいいかわからなくても、まずはテストを書き続けてください。たとえコードを先に書くことになったとしても、その一歩ひとつが確実にTDDへの近道になります。