TDDBC 福岡 1日目午前のメモ

TDDBC 福岡に参加しています。
http://kokucheese.com/event/index/7040/

1日目午前は和田さん( id:t-wada @t_wada )の講演でした。

テストの混乱

皆が重要だという「テスト」だけど、それが指すものは多種多様。その違いを解決しないと、TDDを語ることがまず不可能になる。分類する方法はいくらかあるけれど、テストは何のためにやるかで分けると、以下の三つになる。どのテストももちろん重要。

DeveloperTesting 開発者のため
CustomerTesting 顧客のため
QATesting 品質保証のため

TDDは開発者のためのテスト。テストは現代ソフトウェア開発の三本柱*1の一つ。三本柱は三脚椅子の脚をイメージする。1本でもかけると椅子として成立しない。

DeveloperTesting

旧来よりテスト方法は色々あったが、xUnitはテスト方法の共有化を促進した。テスト方法が共有化されると、テストの実行から属人性*2を排除できる。テスト方法が人に依存しなくなると、テストコードを書いた人以外に引き継げる様になる。誰でも実行できるものは、コンピュータにも実行できる。コンピュータによる自"働"化が実現できる。

よいテストとは

A-TRIP
- Automated
- Through
- Repeatable
- Independent
- Professional
F.I.R.S.T.
- Fast
- Independent
- Repeatable
- Self-Validating
- Timely

テストコードもDRYに書く。きちんと。

動作する、きれいなコード

動作するきれいなコードは最終目標で、到達するのに2つの道がある。出発点は動作しないコード。ひとつは動作しないきれいな設計を作り、それから動作するきれいなコードを作る。よい設計が、よいコードを生ませる。もうひとつが動作するコードをまず作り、そこからきれいにする。よいテストに、よいコードを育てさせる。TDDは後者。

TDDはRed,Green,Refactoringのサイクル。きれいな方向への力はRefactoringしかない。RedとGreenだけでTDDを語ると、単なる動作するコードしかできない。
Redはコードを汚く、動作しなくさせるベクトル。Greenは動作させるだけのベクトル。Refactoringはきれいにするだけのベクトル。二つ以上のことを同時にするとバグが混入しやすいため、ひとつずつやる。

TDD三原則

失敗するテストを書く前に製品コードを書いてはならない
適切に失敗するテストができるまでは、次のテストを書いてはならない
失敗しているテストが通るまで次を書いてはならない

テストを追加できるのは全てのテストが通っている時だけで、追加するテストは常に失敗するもの。一歩一歩進まなければならない。

TDDのこころ

TDD三原則はトテモ厳格。それに対する和田さんのアレンジ。

一つずつ、少しずつ
- 高い塀を乗り越えるには、適切な高さの階段が必要。
- 適切な高さの階段を作るのがTDDのスキル。
ひとりずつ仕留める
- 大きな問題を一気に相手にしない。
- 適切な粒度のテストを一つずつ相手にする。
- 一度にやっちゃうとパンクしてしまう。
すばやくまわす
- TDDはサイクルなので、回転が遅いのでは意味が無い。
- 可能な限り小さく早く回す。
- テストは常にすばやく実行できなけれなばらない。
- そのフィードバックを即座に受ける。
自分が最初のユーザ
- TDDでは間違いなく自分が最初に自分のコードを動かす。
- 使いやすいか使いにくいかすぐにわかる。
- フィードバックを受けて舵取りする。
道具にこだわる
- 常に道具を磨き続ける。
- サイクルを最速でまわせる状態を保つ。
不安をテストにする
- TDDでテストするのは不安なところ。
- これは開発者に依存する。
- 不安の無いところはテストに書く必要が無い。
祈るのではダメ
- TDDは運任せの状態(Edit&Pray)を作らない。
- 緊急時もテストがあればフィードバックが即あるので慌てなくていい。
- 命綱をこつこつ編むのがTDD

私たちは完璧なプログラマではない。最初から書けるほど対象は単純じゃない。近づかないと見えないものは多いので、すばやく対象に近づき、フィードバックを得て方向修正する必要がある。大事なのはフィードバックを得ることで、TDDはその入力を最大限増やすもの。
TDDの工学的なメリットは色々あるが、最大の理由は心理的なもの。