有效的单元测试
前言
对之前的项目进行重构,由于之前的项目中的单元测试大部分都是走走形式,对单元测试疏于管理,运行之后大部分是不通过,这样的单元对项目而言毫无价值,更不要说有助于理解系统功能。这也使我有契机了解到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); } }
代码一 要检查的是什么?位运算符结果怎么算?恐怕大部分使用高级语言的程序员很少会用到,这会增加我们的认知负担。
位运算符可能会有效的执行一个程序,但单元测试的代码可读性优于性能,我们应该更好的表达我们的意图,使用布尔运算符来替换位运算符可以更好的表达意图,见示例二。
1 public void count(){ 2 Data data = project.getData(); 3 assertNotNull(data); 4 assertEquals(4,data.count()); 5 }
第三行代码有些画蛇添足,即使data为空,在没有第三行代码的情况下,测试案例依然会失败,在IDE中双击失败信息,可以快速跳转到失败行,并指出失败原因。所以第三行代码并没有意义,这种防御性策略的真正优势在于方法链中抛出空指针的时候。比如 assertEquals(4,data.getSummary().getTotal()),当此行代码抛出空指针异常时,你无法判断是data为空还是data.getSummary()为空,此时可以先进行assertNotNull(data)的断言。
二、单元测试代码的可维护性
1 //代码一 2 public class TemplateTest(){ 3 @Test 4 public void emptyTemplate() throws Exception{ 5 String template=“”; 6 assertEquals(template,new Template(template).getType()); 7 } 8 @Test 9 public void plainTemplate() throws Exception{ 10 String template=“plaintext”; 11 assertEquals(template,new Template(template).getType()); 12 } 13 }
两个测试方法,一个是测试建立一个空模板,另一个测试建立一个纯文本模板,明显可以发现存在结构性重复,对以上代码进行改进,如下:
1 //代码二 2 public class TemplateTest(){ 3 @Test 4 public void emptyTemplate() throws Exception{ 5 assertTemplateType(“”); 6 } 7 @Test 8 public void plainTemplate() throws Exception{ 9 assertTemplateType(“plaintext”); 10 } 11 private void assertTemplateType(String template){ 12 assertEquals(template,newTemplate(template).getType()) 13 } 14 }
虽然代码行数没有减少,甚至还多了一行,但是把相同的代码提炼到一处,当它发生变动时只需修改一处,可维护性增强了。
1 //重构前 2 public class DictionaryTest{ 3 @Test 4 public void testDictionary() throws Exception{ 5 Dictionary dict = new Dictionary(); 6 dict.add(“A”,new Long(3)); 7 dict.add(“B”,”21”); 8 for(Iterator e = dict.iterator();e.hasNext()){ 9 Map.Entry entry = (Map.Entry) e.next(); 10 if(“A”.equals(entry.getKey())) 11 asserEquals(3L,entry.getValue()); 12 if(“B”.equals(entry.getKey())) 13 assertEquals(“21”),entry.getValue(); 14 } 15 } 16 }
显然当Iterator为空时,测试并不会失败,这并不符合我们单元测试的目的,进行重构后:
1 //重构后 2 public class DictionaryTest{ 3 @Test 4 public void testDictionary() throws Exception{ 5 Dictionary dict = new Dictionary(); 6 dict.add(“A”,new Long(3)); 7 dict.add(“B”,”21”); 8 assertContain(dict.iterator(),”A”,3L); 9 assertContain(dict.iterator(),”B”,21); 10 } 11 private void assertContain(Iterator i,Object key,Object value){ 12 while(i.hasNext()){ 13 Map.Entry entry = (Map.Entry)i.next(); 14 if(key.equals(entry.getKey())){ 15 assertEquals(value,entry.getValue()); 16 return; 17 } 18 } 19 fail("Iterator didn't contain "+ key); 20 } 21 }
counterAccessFromMultipleThreads 用来测试一个多线程计数器,开启10个线程,每个线程调用计数器1000次,sleep(500),是为了让主线程等待开启的10个线程执行完毕
那么问题来了,如果在10毫秒内所有线程都执行完毕,岂不白白浪费了490毫秒?又或者在等待500毫秒后仍有线程没有执行完毕,那该怎么办?
1 @Test 2 public class counterAccessFromMultipleThreads{ 3 final Counter counter = new Counter(); 4 final int callsPerThread = 1000;//每个线程调用计数器1000次 5 final Set<Long> values = new HashSet<Long>(); 6 Runnable runnable = new Runnable(){ 7 public void run(){ 8 for(int i=0;i<callsPerThread;i++){ 9 values.add(counter.getAndIncrement()); 10 } 11 } 12 }; 13 int threads = 10;//开启10个线程 14 for(int i=0;i<threads;i++){ 15 new Thread(runnable).start(); 16 } 17 Thread.sleep(500); 18 int exceptedNoOfValues = threads * callsPerThread; 19 assertEquals(exceptedNoOfValues ,values.size()); 20 }
改进后的测试方法:
1 public class counterAccessFromMultipleThreads{ 2 final Counter counter = new Counter(); 3 final int callsPerThread = 1000; 4 final int numberOfthreads = 10; 5 final CountDownLatch allThreadsComplete = new CountDownLatch(numberOfthreads); 6 final Set<Long> values = new HashSet<Long>(); 7 Runnable runnable = new Runnable(){ 8 public void run(){ 9 for(int i=0;i<callsPerThread;i++){ 10 values.add(counter.getAndIncrement()); 11 } 12 allThreadsComplete.countDown(); 13 } 14 }; 15 16 for(int i=0;i<numberOfthreads;i++){ 17 new Thread(runnable).start(); 18 } 19 allThreadsComplete.await(); 20 // allThreadsComplete.await(10,TimeUnit.SECONDS); 21 int exceptedNoOfValues = threads * callsPerThread; 22 assertEquals(exceptedNoOfValues ,values.size()); 23 }
等待所有线程结束后再继续执行,有更好的办法,java.util.concurrent 包中的CountDownLatch类完全可以胜任这项工作。
调用await方法开始阻塞,直到所有的线程都通知完成,然后继续执行主线程代码。也可以设置超时时间,allThreadsComplete.await(10,TimeUnit.SECONDS); 如果10秒钟内子线程仍未执行结束,也会继续执行主线程。
三、单元测试代码的可维护性
①避免歧义注释
1 /** 2 * 功能描述: 发送邮件<br> 3 * 〈功能详细描述〉 4 * @return 5 * @see [相关类/方法](可选) 6 * @since [产品/模块版本](可选) 7 */ 8
9 public void sendShortMessage() { 10 //todo
11 }
有时候有注释,不如无注释。 可以看到以上代码的注释为发送邮件, 但方法名却为sendShortMessage ,明显为发送短信的意思。这时候我们可能就会想这段代码是要发送邮件还是要发送短信,为了弄清事实不得不去看方法体的内容。 造成这种歧义注释的原因很多,可能之一就是发送短信的方法大致流程可能跟发送邮件相近,所以直接拷贝了邮件的代码,改了方法的内容,却没有修改注释。如果方法名足够得当,可以不写注释。
②避免永不失败的测试
下面的测试代码检查是否抛出期望的异常,这段代码有什么问题?
@Test public void includeForMissingResourceFails() try{ new Environment().include("somethingthatdoesnotexist"); }catch(IOException e){ assertThat(e.getMesssage(),contians(“FileNotExist”)); }
上面的代码测试结果如下:
1.如果代码如期工作并抛出异常,异常会被catch代码块捕获,测试通过。
2.如果代码没有如期工作,也就是没有抛出异常,则方法返回,测试通过,我们并不会发现其中存在的问题。
改进测试方法:
1 try{ 2 new Environment().include(“FileNotEixst”); 3 fail(); 4 }catch(IOException e){ 5 assertThat(e.getMesssage(),contians(“FileNotExist”))}
添加fail()方法的调用,使测试起作用。除非抛出期望的异常,否则测试失败。
四、优秀的单元测试的原则
![](https://images2015.cnblogs.com/blog/853981/201604/853981-20160417212506098-409445945.png)
测试驱动开发流程如上图:在开发前先写一个失败的测试案例,然后写出使测试代码通过的生产代码,重构优化生产代码和测试代码直至通过测试,然后再写一个新的测试,循环上述过程。
当你的生产代码写的一团糟的时候,你很难,甚至是不可能按照优秀单元测试的原则去编写测试代码。比如一个测试方法要求只测试一件事情,而当生产代码一个方法干了很多的事情,测试方法很难保证只测试一件事情,这时候只能重构生产代码才能写出优秀的测试
究其根本,测试驱动开发的本质是,当你的测试代码符合模块化、松耦合高内聚的特点时,生产代码会自然的“被逼迫”遵守同样的原则,从而产生良好的设计。