有效的单元测试

前言

对之前的项目进行重构，由于之前的项目中的单元测试大部分都是走走形式，对单元测试疏于管理，运行之后大部分是不通过，这样的单元对项目而言毫无价值，更不要说有助于理解系统功能。这也使我有契机了解到TDD(测试驱动开发)的思想。为了在项目重构中编写有效的单元测试，我查找了有关TDD的一些书籍，《单元测试的艺术》（Roy Osherove著）和《有效的单元测试》（科斯凯拉著）都是有关测试驱动开发的不错的书籍，前者是使用.net语言，后者使用java语言，作为java程序员我自然选择了后者。但实际上作者在阐述一种思想，不论哪种语言都可以读懂，只是平时的习惯，对于熟悉的语言读起来更顺畅。这篇文章也是对书中的内容做一个总结。

一、单元测试代码的可读性

①使用更易懂的API,把你的代码读出来

示例：

//代码一
String msg = “hello,World”;
assertTrue(msg.indexOf(“World”)!=-1);

//代码二
String msg = “hello,World”;
assertThat(msg.contains(“World”),equals(true));

同样断言字符串中包含 World 这个单词，代码一中 使用indexOf 这个取得单词索引位置的API就显得间接许多，而且我们的大脑还需要对表达式进行判断，进一步增加了认知的负担，而contains 方法字面意思就是包含，更符合我们要表达的意思。所以一定要找到更适合易懂的API。同时用assertThat方法替代assertTrue方法，使的整个语句更具口语化，完全可以像读文章一样读出来

②避免使用较底层的方式，比如位运算符（这并不能表示你有多牛 =.=）

 示例：

//代码一
public class PlatformTest {
    @Test
    public void platformBitLength(){
        assertTrue(Platform.IS_32_BIT ^ Platform.IS_64_BIT);
    }
}

//代码二
public class PlatformTest {
    @Test
    public void platformBitLength() {
        assertTrue("Not 32 or 64-bit platform?", Platform.IS_32_BIT || Platform.IS_32_BIT);
        assertFalse("can't be 32 and 64-bit at the same time.",Platform.IS_32_BIT && Platform.IS_32_BIT);
    }
}

代码一 要检查的是什么？位运算符结果怎么算？恐怕大部分使用高级语言的程序员很少会用到，这会增加我们的认知负担。

 位运算符可能会有效的执行一个程序，但单元测试的代码可读性优于性能，我们应该更好的表达我们的意图，使用布尔运算符来替换位运算符可以更好的表达意图，见示例二。

③不要在测试中对代码进行过度运用防御性策略

public void count(){
        Data data = project.getData();
        assertNotNull(data);
        assertEquals(4,data.count());
} 

第三行代码有些画蛇添足，即使data为空，在没有第三行代码的情况下，测试案例依然会失败，在IDE中双击失败信息，可以快速跳转到失败行，并指出失败原因。所以第三行代码并没有意义，这种防御性策略的真正优势在于方法链中抛出空指针的时候。比如 assertEquals(4,data.getSummary().getTotal())，当此行代码抛出空指针异常时，你无法判断是data为空还是data.getSummary()为空，此时可以先进行assertNotNull(data)的断言。

二、单元测试代码的可维护性

①去除重复，包括结构性重复

//代码一
public class TemplateTest(){
     @Test
    public void emptyTemplate() throws Exception{
        String template=“”;
        assertEquals(template,new Template(template).getType());
   }
    @Test
    public void plainTemplate() throws Exception{
        String template=“plaintext”;
        assertEquals(template,new Template(template).getType());
  }
}

两个测试方法，一个是测试建立一个空模板，另一个测试建立一个纯文本模板，明显可以发现存在结构性重复，对以上代码进行改进，如下：

//代码二
public class TemplateTest(){
     @Test
    public void emptyTemplate() throws Exception{
        assertTemplateType(“”);
    }
    @Test
    public void plainTemplate() throws Exception{
        assertTemplateType(“plaintext”);
    }
   private void assertTemplateType(String template){
      assertEquals(template,newTemplate(template).getType())
   }
}

虽然代码行数没有减少，甚至还多了一行，但是把相同的代码提炼到一处，当它发生变动时只需修改一处，可维护性增强了。

②避免由于条件逻辑而造成的测试遗漏，存在条件逻辑时要在最后加上 fail()方法，强制测试失败

 

 考虑一下，当Iterator 为空的时候，下面的测试方法会失败吗？

//重构前
public class DictionaryTest{ 
@Test
public void testDictionary() throws Exception{
    Dictionary dict = new Dictionary();
    dict.add(“A”,new Long(3));
    dict.add(“B”,”21”);
    for(Iterator e = dict.iterator();e.hasNext()){
        Map.Entry entry = (Map.Entry) e.next();
        if(“A”.equals(entry.getKey()))
            asserEquals(3L,entry.getValue());
        if(“B”.equals(entry.getKey()))
            assertEquals(“21”),entry.getValue();
     }
  }
}

 显然当Iterator为空时，测试并不会失败，这并不符合我们单元测试的目的，进行重构后：

//重构后
public class DictionaryTest{ 
@Test
public void testDictionary() throws Exception{
    Dictionary dict = new Dictionary();
    dict.add(“A”,new Long(3));
    dict.add(“B”,”21”);
    assertContain(dict.iterator(),”A”,3L);
        assertContain(dict.iterator(),”B”,21);
  }
private void assertContain(Iterator i,Object key,Object value){
        while(i.hasNext()){
            Map.Entry entry = (Map.Entry)i.next();
            if(key.equals(entry.getKey())){
                assertEquals(value,entry.getValue());
            　　 return;
            }
        }
        fail("Iterator didn't contain "+ key);
    }
}

 当没有达到预期目的时使用 fail()方法，强制测试失败。

 

 ③避免使用sleep方法浪费大量的测试时间

counterAccessFromMultipleThreads 用来测试一个多线程计数器，开启10个线程，每个线程调用计数器1000次，sleep(500),是为了让主线程等待开启的10个线程执行完毕

那么问题来了，如果在10毫秒内所有线程都执行完毕，岂不白白浪费了490毫秒？又或者在等待500毫秒后仍有线程没有执行完毕，那该怎么办？

@Test
public class counterAccessFromMultipleThreads{
  final Counter counter = new Counter();
  final int callsPerThread = 1000;//每个线程调用计数器1000次
  final Set<Long> values = new HashSet<Long>();
  Runnable runnable = new Runnable(){
      public void run(){
          for(int i=0;i<callsPerThread;i++){
              values.add(counter.getAndIncrement());
          }
      }
  }; 
  int threads = 10;//开启10个线程
  for(int i=0;i<threads;i++){
      new Thread(runnable).start();
  }
  Thread.sleep(500);
  int exceptedNoOfValues = threads * callsPerThread;
  assertEquals(exceptedNoOfValues ,values.size());
}

改进后的测试方法：

public class counterAccessFromMultipleThreads{
  final Counter counter = new Counter();
  final int callsPerThread = 1000;
  final int numberOfthreads = 10;
  final CountDownLatch allThreadsComplete = new CountDownLatch(numberOfthreads);
  final Set<Long> values = new HashSet<Long>();
  Runnable runnable = new Runnable(){
      public void run(){
          for(int i=0;i<callsPerThread;i++){
              values.add(counter.getAndIncrement());
          }
          allThreadsComplete.countDown();
      }
  }; 

for(int i=0;i<numberOfthreads;i++){
      new Thread(runnable).start();
  }
  allThreadsComplete.await();
  //  allThreadsComplete.await(10,TimeUnit.SECONDS);
  int exceptedNoOfValues = threads * callsPerThread;
  assertEquals(exceptedNoOfValues ,values.size());
}

 　　等待所有线程结束后再继续执行，有更好的办法，java.util.concurrent 包中的CountDownLatch类完全可以胜任这项工作。

　　调用await方法开始阻塞，直到所有的线程都通知完成，然后继续执行主线程代码。也可以设置超时时间，allThreadsComplete.await(10,TimeUnit.SECONDS); 如果10秒钟内子线程仍未执行结束，也会继续执行主线程。

三、单元测试代码的可维护性

 ①避免歧义注释

 /**
     * 功能描述: 发送邮件<br>
     * 〈功能详细描述〉
     * @return
     * @see [相关类/方法](可选)
     * @since [产品/模块版本](可选)
     */
　　 
 9 　　public void sendShortMessage() {
   　　 //todo
   }
    

　　有时候有注释，不如无注释。 可以看到以上代码的注释为发送邮件， 但方法名却为sendShortMessage ,明显为发送短信的意思。这时候我们可能就会想这段代码是要发送邮件还是要发送短信，为了弄清事实不得不去看方法体的内容。 造成这种歧义注释的原因很多，可能之一就是发送短信的方法大致流程可能跟发送邮件相近，所以直接拷贝了邮件的代码，改了方法的内容，却没有修改注释。如果方法名足够得当，可以不写注释。

②避免永不失败的测试

下面的测试代码检查是否抛出期望的异常，这段代码有什么问题？

@Test
public void includeForMissingResourceFails()
    try{
        new Environment().include("somethingthatdoesnotexist");
       }catch(IOException e){
        assertThat(e.getMesssage(),contians(“FileNotExist”));
}

上面的代码测试结果如下：

1.如果代码如期工作并抛出异常，异常会被catch代码块捕获，测试通过。

2.如果代码没有如期工作，也就是没有抛出异常，则方法返回，测试通过，我们并不会发现其中存在的问题。

改进测试方法：

try{
        new Environment().include(“FileNotEixst”);
        fail();
   }catch(IOException e){
   assertThat(e.getMesssage(),contians(“FileNotExist”))}

 添加fail()方法的调用，使测试起作用。除非抛出期望的异常，否则测试失败。

四、优秀的单元测试的原则

　　　　•少用继承多用组合，继承更大程度上是为了多态而非复用代码

　　　　•单元测试应该模块化，每个模块小而专注，减少反馈链

　　　　•如果一个单元测试方法失败了，那么导致它失败的原因只有一个

　　　　•加载外部文件时使用相对路径而不是绝对路径

　　　　•对于魔法数字除了提取局部变量或常量外，可以取一个恰当的方法名，见名知义

　　　　•好的注释应解释代码现状的缘由

　　可以看出优秀的单元测试的原则跟优秀的面向对象编程的原则一致,比如少用继承，多用组合，模块化且模块尽可能小，一个模块只完成一个功能等。

 

五、BBD测试驱动开发

 

 

　

　　测试驱动开发流程如上图：在开发前先写一个失败的测试案例，然后写出使测试代码通过的生产代码，重构优化生产代码和测试代码直至通过测试，然后再写一个新的测试，循环上述过程。

　　当你的生产代码写的一团糟的时候，你很难，甚至是不可能按照优秀单元测试的原则去编写测试代码。比如一个测试方法要求只测试一件事情，而当生产代码一个方法干了很多的事情，测试方法很难保证只测试一件事情，这时候只能重构生产代码才能写出优秀的测试

　　究其根本，测试驱动开发的本质是，当你的测试代码符合模块化、松耦合高内聚的特点时，生产代码会自然的“被逼迫”遵守同样的原则，从而产生良好的设计。