标签：
前言
对之前的项目进行重构，由于之前的项目中的单元测试大部分都是走走形式，对单元测试疏于管理，运行之后大部分是不通过，这样的单元对项目而言毫无价值，更不要说有助于理解系统功能。这也使我有契机了解到BBD(测试驱动开发)的思想。为了在项目重构中编写有效的单元测试，我查找了有关BBD的一些书籍，《单元测试的艺术》（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()方法的调用，使测试起作用。除非抛出期望的异常，否则测试失败。
四、优秀的单元测试的原则
测试驱动开发流程如上图：在开发前先写一个失败的测试案例，然后写出使测试代码通过的生产代码，重构优化生产代码和测试代码直至通过测试，然后再写一个新的测试，循环上述过程。
当你的生产代码写的一团糟的时候，你很难，甚至是不可能按照优秀单元测试的原则去编写测试代码。比如一个测试方法要求只测试一件事情，而当生产代码一个方法干了很多的事情，测试方法很难保证只测试一件事情，这时候只能重构生产代码才能写出优秀的测试
究其根本，测试驱动开发的本质是，当你的测试代码符合模块化、松耦合高内聚的特点时，生产代码会自然的“被逼迫”遵守同样的原则，从而产生良好的设计。
标签：
原文地址：http://www.cnblogs.com/jarman/p/5272761.html
