六、测试驱动开发 TDD
在编写业务代码前，先考虑如何编写测试，再编写业务代码，这种开发方式称作：TDD test-driven development。
使用TDD的主要优点
就通常的单元测试而言，最为明显优点就增强了我们对代码按照设计运行的信心。
而TDD，由于是在编写业务代码提前设计，可以说，这些单元测试就反映了业务需求（当然依赖单元测试的质量），为重构提供了保障。
简单的开始
下面的例子是一个完整的TDD的流程，目的是实现Profile类。一遍遵循如下的流程：
- 编写一个会失败的测试
- 通过编写新的代码使得测试通过
- 清理掉无效代码并重复上面的步骤
首先编写最简单测试用例与业务代码
package iloveyouboss;
import static org.junit.Assert.assertFalse;
import org.junit.Test;
public class ProfileTest {
@Test
public void matchesNothingWhenProfileEmpty() {
Profile profile = new Profile();
}
}
这是肯定会出现编译错误，原因是没有Profile类，此时我们建立一个最简单的Profile，仅满足测试用例不报错。Profile类如下：
package iloveyouboss;
public class Profile {
}
现在改进一下测试用例
补充测试用例的内容，让用例先失败，再成功。
package iloveyouboss;
import static org.junit.Assert.assertFalse;
import org.junit.Test;
public class ProfileTest {
@Test
public void matchesNothingWhenProfileEmpty() {
Profile profile = new Profile();
Question question = new BooleanQuestion(1, "Relocation package?");
Criterion criterion = new Criterion(new Answer(question, Bool.TRUE), Weight.DontCare);
boolean result = profile.matches(criterion);
assertFalse(result);
}
}
假定其他依赖的类均存在，此时profile.matches()方法会报错，原因是没有matches方法。这时修改Profile类：
package iloveyouboss;
public class Profile {
private Answer answer;
public boolean matches(Criterion criterion) {
return answer != null;
}
public void add(Answer answer)
{
this.answer = answer;
}
}
清理测试
在经过上面的循环之后，我们发下这两个测试用例均初始化了Profile，因此可以将其提权到@Before函数中。
public class ProfileTest {
private Profile profile;
@Before
public void createProfile()
{
profile = new Profile();
}
....
}
TDD美好的地方在于，在特性之前编写测试，也就意味着可以始终对重构和清理代码充满信心。
我们还可以不断的重构测试，如提取公共的变量到@Before中，对变量进行重命名以提高可读性，使得单元测试能够明确的表述功能，并自然的成为文档的一部分。下面是经过重构后的测试代码，可以看到profile, questionIsThrereRelocation， answerThereIsRelocation被提取和改名了。
package iloveyouboss;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import org.junit.Before;
import org.junit.Test;
public class ProfileTest {
private Profile profile;
private BooleanQuestion questionIsThereRelocation;
private Answer answerThereIsRelocation;
@Before
public void createProfile() {
profile = new Profile();
}
@Before
public void createQuestion() {
questionIsThereRelocation = new BooleanQuestion(1, "Relocation package?");
answerThereIsRelocation = new Answer(questionIsThereRelocation, Bool.TRUE);
}
@Test
public void matchesNothingWhenProfileEmpty() {
Criterion criterion = new Criterion(answerThereIsRelocation, Weight.DontCare);
boolean result = profile.matches(criterion);
assertFalse(result);
}
@Test
public void matchesWhenProfileContainsMatchingAnswer() {
profile.add(answerThereIsRelocation);
Criterion criterion = new Criterion(answerThereIsRelocation, Weight.Important);
boolean result = profile.matches(criterion);
assertTrue(result);
}
}
再一次改进
这次增加一个测试用例，用来覆盖答案不能覆盖问题的场景，首先增加一个用例：
@Test
public void doesNotMatchWhenNoMatchingAnswer() {
profile.add(answerThereIsNotRelocation);
Criterion criterion = new Criterion(answerThereIsRelocation, Weight.Important);
boolean result = profile.matches(criterion);
assertFalse(result);
}
这里用例是执行不通过的，然后通过修改profile类使得该测试通过：
package iloveyouboss;
public class Profile {
private Answer answer;
public boolean matches(Criterion criterion) {
return answer != null && answer.match(criterion.getAnswer());
}
public void add(Answer answer) {
this.answer = answer;
}
}
作为开发者，工作就是考虑代码中所有的可能性和场景。如果要取得TDD的成功，需要将这些场景拆分为测试，并将他们按照一定的顺序排列，以减少使得每个测试通过的代码增量。
将测试作为文档一部分
对于TDD，测试用例应该作为文档的一部分，其他开发者可以通过阅读测试用例来了解内部逻辑，这要求测试用例的名称足够清晰。如：
matchesWhenProfileContainsMatchingAnswer doesNotMatchWhenNoMatchingAnswer matchesWhenContainsMultipleAnswers doesNotMatchWhenNoneOfMultipleCriteriaMatch matchesWhenAnyOfMultipleCriteriaMatch doesNotMatchWhenAnyMustMeetCriteriaNotMet matchesWhenCriterionIsDontCare scoreIsZeroWhenThereAreNoMatches
另外，为了清晰，也可以将不同关注点的测试用例放到不同的测试类中。
TDD的节奏
TDD遵循一个普遍的循环：
- 编写测试
- 编写逻辑使得测试通过
- 重构代码保持清晰
- 重复上述过程
最好将每次循环控制得足够小，例如10分钟以内，如果10分钟不能完成则说明测试的粒度有些大，需要重新写测试，这样不断循环，逐渐逼近和完善功能。
最终交付的，将不只是代码，同时提供了作为文档使用的测试用例以及重构的保证。
