《Effective Unit Testing》 读书笔记 8 可信任性 code smell

如何理解可信任性（Trustworthiness ）？可以用人做比较，一个可信任的人言出必行，而一个不可信任的人说的话不算数、承诺的事做不到。测试也是如此。这章介绍影响可信任性的code smell.

1. 被注释掉的测试
   简单得说，被整个注释掉的测试还不如把这部分代码直接删掉。我们有版本管理工具，根本不用担心找不回被删掉的代码。

2. 误导人的注释
   误导人的注释比没有注释更可怕。另外说一句，通过好的方法名和变量名通常我们能做到尽量不写注释。一定要写注释的的话，注释应该是解释why，而不是说明what。比如我们写了个很丑陋的循环，我们不需要解释这个循环做什么，这是起个好的方法名就可以达到的功能，但我们可以写注释说明非要这么写的理由（比如为了更好的性能）。

3. 从不会失败的测试
   这种情况的出现，一般是因为测试的assert只存在于某个条件分支中。一种特别要注意的情况是把assert写在了catch语句里。见下面这个例子。

 @Test
public void includeForMissingResourceFails() {
  try {
    new Environment().include("somethingthatdoesnotexist");
  } catch (IOException e) {
    assertThat(e.getMessage(), contains("somethingthatdoesnotexist"));
  }
}

这个方法如果没有抛exception，测试同样是能通过的，但这并不是我们想要的结果。之所以测试能通过是因为我们忘记了在条件不满足的情况下让这个测试失败。改进方法很简单，加入fail()。

 @Test
public void includeForMissingResourceFails() {
  try {
    new Environment().include("somethingthatdoesnotexist");
    fail();  //
  } catch (IOException e) {
    assertThat(e.getMessage(), contains("somethingthatdoesnotexist"));
  }
}

4. 浅承诺 （shallow promises)
   这是指测试并没有实际上校验它的名字所宣称要校验的内容。

5. 降低的期待（lowered expectations)
   这是像素级精确的反面，只是粗略地判断了所要assert的逻辑，比如我们只是验证某方法返回值不为空，但是不去看实际内容对不对。测试太粗略了就导致它应该fail的时候不fail。如何在过于精确和过于粗略中把握度是一种艺术。

6. 平台偏见
   这个问题出现在要测试一段代码功能，这段代码需要在不同的平台表现出不同的行为，比如返回正确的用户目录。
   有意思的是，解决这个问题的正确方式不是在测试代码这头，而是在设计功能性代码时就要把平台这个概念抽象出来，不能依赖跑测试所在机器实际上的平台。

7. 条件化测试（conditional tests）
   assert出现在某个条件分支中。这导致如果测试没跑到这个条件中，测试照样能通过。举个例子：

@Test
public void multipleArgumentsAreSentToShell() throws Exception {
  File dir = createTempDirWithChild("hello.txt");
  String[] cmd = new String[] { "ls", "-1", dir.getAbsolutePath() };
  Process process = new Process(cmd).runAndWait();
  if (process.exitCode() == 0) {
    assertEquals("hello.txt", process.output().trim());
  }
}

解决的大原则是，所有条件分支都要跑到，而且所有分支要有测试fail的可能性。其实代码中就不应该出现条件分支，而应该为每个分支建立单独的测试方法。

code smell的介绍通过可读性，可维护性，可信任性三篇文章就到此结束了，下一章将介绍我比较感兴趣的内容：可测试的设计，testable design。