テスト駆動開発を行う上で欠かせない「テスト駆動開発の基本サイクル」を解説します。Kent Beck の著作「テスト駆動開発」にもある通り、テスト駆動開発は一定の行動を短期間で行いながら徐々に実装コードを大きくしていく作業です。
この記事ではテスト駆動開発を行う上で、絶対に理解しておくべき「テスト駆動開発のサイクル」を解説していきます。テスト駆動開発はここで解説する3つの行動がとても基本になりますので、必ず理解しておくべき内容となります。
テスト駆動開発の3つのサイクル
テスト駆動開発はテストコードを主軸として、テスト・実装・リファクタリングを短期間でイテレーティブに行っていき、徐々に機能の風呂敷を風呂敷を広げながら進んでいく開発手法になります。テスト駆動開発は、大きく分けると3つのサイクルがあります。
- レッド
- グリーン
- リファクタリング
この3つを素早く行っていくことがテスト駆動開発のメイン部分になります。それぞれのパートについて簡単に解説していきます。実際のやり方は連載をもう少し進めた所で実践していきます。今は「レッド→グリーン→リファクタリングなんてあったな」くらいでOKです。
【レッド】：失敗
テスト駆動開発はテストファーストな手法ですが、テストを書く際にまずは「失敗」するようにします。機能の要件を基にしてテストコードを書いていきますが、最初はプロダクトコード側には手を入れずにテストコードだけを書いていきます。
プロダクトコードに記載されていないコードで問題ありません。まずはテストコードを書いていく段階です。この時に重要なのは「自動テストが認識されているか」です。テストコードを書いたとしても自動テストとして認識されていなければ意味がありませんので、ちゃんと「テストとして認識されているか」を確認する上でも失敗するのは重要になります。
この「失敗している状態」をレッドと呼んでいます。その理由はテスト結果を確認する箇所にレッドバー（もしくはレッドのアイコン）が表示されるからです。
Visual Studioでは上記のように失敗しているテストケースは赤の×マークが表示されていますね。要するに「失敗」という状態を「レッド」と呼んでおり、この状態がテスト駆動開発におけるスタート地点となるのです。
【グリーン】：とりあえずの成功
「レッド」にて失敗するテストコードを書いた後は、とりあえずテストが成功するようにコードを書いていきます。ここで重要になるのは「どんな方法でもよい」という点です。効率性や可読性はおいておき、まずはテストが通るプロダクトコードを仕上げます。
「グリーン」も「レッド」と同様にテスト結果を示す箇所が「緑色」になることに由来しています。「レッド」が危険をイメージさせるように、「グリーン」は安心をイメージできるような感じですね。Visual Studioでは以下のようにグリーンが表示されます。
テスト駆動開発においては、このグリーンの状態を保つことが重要となります。というのもグリーンの状態は「テストに通っている安心なコード」を意味するからです。レッドからグリーンに変化させる1回目はとりあえずテストをクリアすることを目指します。
「グリーン」な状態のプロダクトコードを書き上げることで「最低限の成功」が保証されることを意味します。テスト駆動開発では、このグリーンな状態を保ちながら、より良い方法や可読性の高いコードを探っていきます。
【リファクタリング】：昇華
一度テストが「グリーン」の状態になったら、簡潔でより良いコードを目指していきます。テストに通っているので、最低限の処理・動作は保証されていますので、あとはこの「グリーン」の状態を保ちながら、リファクタリングを行っていけばよいのです。
テストが「グリーン」の状態である以上は、修正内容に問題ないことを保証しているのが心強く感じます。リファクタリングで怖いのは「デグレ」ですが、「グリーン」である以上は動作に影響がないことを保証してくれます。
テスト駆動開発のサイクルを回そう
テスト駆動開発はここで紹介した「レッド」「グリーン」「リファクタリング」のサイクルをなるべく早く回していく開発手法です。兎にも角にも、まずはテストコードを書くことから始め、そのテストケースを満たすプロダクトコードを記述していきます。そのあと良いコードを探すためのリファクタリングを行っていきます。
この一連の動作をテストケースを作成しながら進んでいきます。最初の方が小さな部品から作っていくことになると思いますが、次第にそれらが集まっていき、徐々にアプリケーションとしての形が見えるようになっていくはずです。
テストコードを書いていくということは機能・要件をきっちりと理解していなければできないことですので、テスト駆動開発は「業務に目を向けた構築方法」ともいえるかもしれません。単純なスキルだけでなく、適切なテストケースを見極める能力が問われていく開発手法ともいえるでしょう。
