２章

TDDの目標

1. 動作する
2. きれいな

ここでは、動作→きれいな
逆はアーキテクチャ駆動と言っている

id:t-wadaさんの話だと、どちらからでもよい

とにかくはやくグリーンにしたい

リズムが重要

Dollarオブジェクトが変化する

こんなテストを用意

package star.Test;

import star.Dollar;
import junit.framework.TestCase;

public class DollarTest extends TestCase {
	public void testMultiplication() {
		Dollar five = new Dollar(5);
		five.times(2);
		assertEquals(10, five.amount);

		five.times(3);
		assertEquals(15, five.amount);
	}
}

timesメソッドが新しいオブジェクトを返してあげればよい

Dollarオブジェクトのインターフェースを変更
＞このことをオブジェクトの退化っていってるのかな？

正しいインターフェースについての推測は、正しい実装についての推測と同様に完全でない
＞インターフェースを決めても揺らぐことはあるよってことだね。

まず、テストクラスを変更

public class DollarTest extends TestCase {
	public void testMultiplication() {
		Dollar five = new Dollar(5);
		Dollar dollar = five.times(2);
		assertEquals(10, dollar.amount);
		
		dollar = five.times(3);
		assertEquals(15, dollar.amount);
	}
}

timesメソッドの仕様が変更されたので、ターゲットクラスも変更

	public Dollar times(int multiplier) {
		return new Dollar(amount*multiplier);
	}

ここまでで、TDDの戦略３つのうちの２つ

• 仮実装
• 明白な実装

普段はこの二つを使って行う。
これが、リファクタの階段？

• 飛ばしたり
• 慎重になったり

TDD共通のテーマ

• 感情をテストにする
• コードに対する不快感、不安感をテストケースの量に変化

読み返してみると、ほんとさらっと重要なことを書いてるな。