TDD bootcampに行ってきました
TDD、なんて甘美で素晴らしい響きなんでしょうか。 というわけで7/1に大阪で開催されたTDD Bootcampの感想を書きたいと思います。
TDDとは
テスト駆動開発のこと….わからん まずテストコードを書いてから、プロダクトコードを書きましょうという思想。 テストファーストだとか言わます。 詳細はぐぐってください。
TDD Bootcampは座学と実習を通してTDDの入門学習を行う集まりです。
品質テスト≠開発テスト
テストと聞くとプロダクトのリリース前に行うテストをイメージします。
しかし、これら品質の確認の為のテストとTDDで扱うテストは別物のようです。
ここを勘違いするとTDDの説明を聞いてもしっくりこないと思います。
TDDで扱うテストはプログラマが安心してコーディングを行うためのものです。
プログラマが安心するためにテストコードは２つの役割があるのだなと思いました。
テストコード＝ゴールへの道標
TDDはRed → Green → Refancoringのサイクルで回します。
TDDの最大の特徴は、まず失敗するテストを追加して（Red）からプロダクトコードを追加／修正する（Green）という点です。
『Assert First』などとも呼ばれるこの原則はテストコードは道標の役割を持ちます。
作りたい製品にたいして、さしあたって達成すべきチェックポイント、それをテストコードという明確な形で見える化する。
目標達成におけるKPIに近い考え方だと私は思います。
遠すぎるゴールに対してチェックポイントを置いていくことで道を見失わないようにする。
様々な分野で見受けられるこのベストプラクティスはコーディングの世界にも通じるようです。
進むべき道先を照らすことでプログラマは安心して機能を追加する（攻める）事ができます。
テストコード＝デグレ検出器
プログラマにとってシステムダウンの次に怖いのはデグレ。
即ち、プログラムの変更により今まで使えていた他の機能が使えなくなること。
そもそもゴミコードがゴミのまま放置されるのは、
- 「動いてるコードを触って壊れたら心配」
- 「ゴミだけどとりあえず動いてるからそっとしておこう」
という保守的な考えによるもの。
TDDのテストコードは一度書くとユーザーが消すまでこまめに実行され続けます。
これによりデグレを起こしたら直ちに検出できる（守れる）ようになります。
デグレにすぐに気付ける体制があって初めて安心してリファクタリングをすることができます。
まとめ
TDDはテスト駆動と銘打っていますが、動くチェックリストという方が近い感覚です。
高度な自動化技術やJUnitなどのライブラリが目立ちますが、それは手間を省く周辺技術で、本質的には誰でも導入できるものです。
高度な技術的手法というより堅実な仕事の進め方と考えたほうが良いでしょう。
ちょっと気軽にTDD始めてみませんか？
