TDDのサイクル

数年前にt_wadaさんのTDD実践講座に参加した際に説明いただいたTDDのサイクルについての覚書です。

TDDとは

テスト駆動開発（Test Driven Development）の略称。
テストを書いてからコーディングを行うという開発手法です。
テストを先に書くためテストファーストと言われています。

TDDのサイクル

テスト駆動開発は以下のサイクルをひたすら回して、動作するきれいなコードに近づけていきます。

1. 次の目標を考える
2. その目標を示すテストを書く
3. テストを実行して失敗させる（Red）
4. 目的のコードを書く
5. 2のテストを成功させる（Green）
6. テストが通るまでリファクタリングを行う（Refactor）
7. ↑を繰り返す

1. 次の目標を考える

• 紙なり、テキストファイルなりにTODOリストを作成
• コードを書き始めるより前に冷静な頭で作成するのが良い。
  • コードを書きだすと視野が狭くなるため

2. その目標を示すテストを書く

• 書き出した目標からテストするものを選ぶ。
• 一番倒せそうな目標から手をつける
  • 大きめのものは結局細分化する羽目になるため難しい
• 1サイクルにつき、倒すテストは必ず1つにする!!

3. テストを実行して失敗させる（Red）

• 必ずテストが失敗することを確認する
• ちゃんと期待したエラーになっているかを確認してから、次のステップへ進むこと
  • これを怠ると、進めていく途中でエラーになった場合
    実装したコードが悪いのか、テストの書き方が悪いのか
    明確な原因が掴みづらくなる。

4. 目的のコードを書く

TDDは"動作する"コードを書いてから"きれいな"コードにする

• ここで重要なのは、"最短"でテストが通るようにコードを書くこと。
• どれだけ汚くてもかまわない。"動作する"を優先する

この辺はテスト駆動開発の書籍を進めても面喰らうんですが、普通に組んでるとまず書かないようなコードを書かされます。
でもそれでいいんです。

5. 2のテストを成功させる（Green）

• ここまでくると、"動作する"は倒せたことになる。Congratulation!🎉

6. テストが通るままでリファクタリングを行う（Refactor）

リファクタリングとは

ソフトウェアから見た外部のふるまいを変えないまま内部の品質をあげること

• テストが成功した状態を維持したまま、プロダクトコードをキレイにしていく
• ある程度書いたらこまめにテストを実行
• テストがGreenである間はOK
• Redになったら、動作を壊す変更が行われているので見直す
• 書いてる間に気づいたことがあった場合、TODOリストの改定も行う
• キレイにする、には終わりがないのである程度時間は決めておく
• 5でGreenにした段階の雑なコードでは、重複するコードが生まれることが多いので
  それを取り除いたら次にいく、くらいでもいい

7. 1~6を繰り返す

• 完了した項目はTODOリストから削除、次のTODOに取り組む

---

以上がTDDのサイクルになります。