clean code - 单元测试

TDD三定律

定律一： 在编写不能通过的单元测试前，不可编写生产代码。
定律二： 只可编写刚好无法通过的单元测试，不能编译也算不通过。
定律三： 只可编写刚好足以通过当前失败测试的生产代码。

保持测试整洁

• 测试代码的维护应遵循生产代码的质量标准-测试代码和生产代码一样重要。
  测试代码也要有良好的设计和划分。
  测试必须随生产代码的演进而修改。
• 单元测试让你的代码可扩展、可维护、可复用。

整洁的测试

整洁测试三要素：可读性，可读性和可读性。

public void testGetHieratchyAsXml() throws Exception{    crawler.addPage(root,PathParser.parse("PageOne"));    crawler.addPage(root,PathParser.parse("PageOne,ChildOne"));    crawler.addPage(root,PathParse("PageTwo"));    request.setResource("root");    request.addInput("type","pages");    Response responder = new SerializedPageResponder();    SimpleResponse response =  (SimpleResponse)responder.makeResponse(    new  FitNesseContext(root),requst);    String xml = response.getContent    ();    assertEquals("text/xml",response.getContentType());    assertSubString("<name>PageOne</name>",xml);    assertSubString("<name>PageTwo</name>",xml);    assertSubString("<name>ChildOne</name>",xml);}

public void testGetPageHierarchyAsXml() throws Exception{    makePages("PageOne","PageOne.Child","PageTwo");    submitRequrst("root","type:pages");    assertResponseIsXML();    assertResponseContain("<name>PageOne</name>","        <name>PageTwo</name>","<name>ChildOne</name>");}

测试呈现 BUILD-OPERATE-CHECK 模式 ，每个测试逗清晰的拆分为三个环节：第一构造测试数据，第二操作测试数据，第三检验操作是否得到期望结果。

每个测试一个断言

• 有很多人认为：JUnit中每个测试函数都应该有且只有一个断言语句。

public void testGetHierarchyAsXml() throws Exception{    givenPages("PageOne","PageOne.ChildOne","PageTow");    whenRequestIsIssued("root","type:pages");    thenResponseShouldBeXML();}public void testGetPageHierarchyHasRightTags() throws Excption{    givenPages("PageOne","PageOne.ChildOne","PageTwo");    whenRequestIsIssued("root","type:pages");    thenResponseShouldContain("<name>PageOne</name>",        "<name>PageTwo</name>","<name>ChildOne</name>");}

• 最好的说法是单个测试中的断言数量应该最小化。
• 更好的一些规则或许是每个测试函数中只测试一个概念。

F.I.R.S.T.

整洁的测试遵循一下5条规则：
- 快速
- 独立：某个测试不应为下一个测试设定条件。
- 可重复：测试应当可在任何环境中重复通过。
- 自足验证：测试应该有布尔值输出，无论通过或失败，你不应该查看日志文件来确认测试是否通过。
- 及时：单元测试应该恰好在使其通过的生产代码之前编写。