Highlight
TDDのリズム
- まずはテストを1つ書く
- 全てのテストを走らせ、新しいテストの失敗を確認する
- 小さな変更を行う
- 全てのテストを走らせ、全て成功することを確認する。
- リファクタリングを行って重複を除去する。
何をテストすべきか？
TODOリストで管理する
これから数時間で何をやるか？細かい粒度でまとめる
・実装しなければいけないふるまい
・空実装
・リファクタリング
アサートファースト
まず最初にアサーションを書く。
問題を分けるためにまず「正しい結果」を書き、次に「それをどう検証するか」を書く。
はじめのテスト
初めに書くテストは「そこから学ぶものがありそうで、かつ、すぐ書けそうなテスト」を選ぶ。
抽象度の高いアプリケーションテストに近いものになるはず。
Socket socket = new Socket();
String message = 'hello';
socket.write(message);
assertEquals(message, socket.read());小さいテスト
大きいテストが失敗したときは、問題箇所を絞り込んだ小さいテストを書いてそれだけを走らせる。
A,B,Cをそれぞれ動かせるようになれば組み合わせて動かすことも難しくない。
仮実装
失敗するテストを書いた後、まず最初に行う実装はベタ書きの値を返すこと。
だんだん本物の式や変数に置き換える。
「動くコード」と「きれいなコード」を分離して、目の前のスコープに集中できる効果がある
@Test
public void testSum() {
assertEquals(4, plus(3, 1));
}
private int plus(int augend, int addend) {
return 4;
}
三角測量
テストから一般化を引き出す。
@Test
public void testSum() {
assertEquals(4, plus(3, 1));
assertEquals(7, plus(3, 4)); // 追加
}
private int plus(int augend, int addend) {
return 4; // fail!
}
リファクタリング
よく似ているコードを共通化するためには、コードの内容をだんだん近づけていく。そして完全に一致したらひとつにまとめる。
- ループ構造が似ている
- 条件分岐の中身が似ている
- メソッドが似ている
- クラスが似ている
TDDの「T」はテストの一部に過ぎない
テストとは、エラーを見つけるつもりでプログラムを実行する過程である。
つまり、認知の外を探求すること。
TDDのテストはプログラミングや設計の補助である。（＝Checkingである）
以下のアジャイルテストの4象限における、Q1に当たる。
テストとは、以下の4象限すべてを網羅していなければならない。
BDD（Behavior Driven Development）
TDDはテスト技法ではなく、分析技法であり、設計技法であり、開発アクティビティを構造化する技法である。
それはつまり、テストではなく「ふるまい」である。
TDD(xUnit系)の語彙を再定義したのがxSpec系のテスティングフレームワーク。
assertion → expectation
test → example
BDDでは、ダブルループの外側（ATDD - Acceptance Test Driven Development）を顧客に参加してもらう。
Cucumberというフレームワークを使えば、自然言語で受け入れテストを書くことができる。
TDDはスキル
TDDは個人のプラグラミングテクニックである。
賛同者がいなくても始められるので、自分自身で修練を積んで良いテストコードを書けるようになる。
優れたプログラミングテクニックやパラダイムは「使いすぎてみて」少し戻ってくるくらいがいい塩梅。
TDD・デザインパターン・DDD・関数プログラミング…、全て手を出してみて、夢中になり、正気に戻り、良いと思ったエッセンスを自分の中に残して下さい。
経験を積んだ開発者は、テストコードの書き方や量、書くタイミングに関して自分の間合いを持っています。さまざまなパラダイム、テクニックを経験して戻ってきたところが、唯一無二の自分のプログラミングスタイルです。様々な世界を経験し、自分のスタイルを見つけてください。