编写可读代码的艺术 - 测试与可读性

使测试易于阅读和维护

测试代码和业务代码一样重要，测试的目的不是为了让测试通过，测试的主要目的是为了确保代码的改动不会影响到现有的逻辑。所以写代码的时候应当尽量使每一个测试的目的明确。

今天开始尝试给新写的类写测试了，比较简单的测试方法就是IDEA自动生成的，给每一个public方法写一个测试

public class Parser {
  public void method1() {}
  public void method2() {}
}

public class ParserTest{
  private Parser parser;
  
  @Before
  public void init() {
    this.parser = new Parser();  
  }
  
  @Test
  public void method1Test() {
    
  }
  
  @Test
  public void method2Test() {
    
  }
}

这样写的问题就是每一个方法的不同case都写在同一个测试方法里了。其实应该分散在不用的方法里，并且用方法名体现不同的使用场景

让错误消息更具有可读性

现在的Test框架已经都支持了

比如Assert.assertEquals(a, b)，如果不相等就会报错：expect: ..., actual: ...。今天写测试一个小方法get值get错了就直接被看出来了，还是很有用的

选择好的测试输入

测试的数据应该以简单为主，没有必要是真正生产的测试数据。这样mock数据会比较方便，而且如果测试出错了也比较方便定位原因

测试函数命名

测试函数命名尽量以test开头，不需要担心函数名太长。测试的函数名要表达出测试的case，因为也不会在业务逻辑中使用，不用担心函数名太长

可测试性好的测试

1. 类中的内部状态很少

   这样的话对于类内部状态的设置就相对简单，编写测试比较方便

2. 函数只做了一件事

   这也是我最近写测试能体会到的，如果一个函数过于复杂了，那么要测试的流程就会变得很多，就容易出现测试不到的地方。并且函数做的事情多了，就容易大量依赖其它的内容，编写测试就会变得麻烦