Junit内部解密之四: Junit单元测试最佳实践

发表于:2012-06-19来源:新浪博客作者:JerryGao点击数: 标签:Junit单元测试
我们做使用Junit工具来做单页测试或接口测试时,需要注意一些问题,包括我们的编码规范,test规范,以及编写测试代码的策略,以下个人的总结。 1.为还没有实现的测试代码抛出一个异常。这就避免了该测试通过,而且会提醒你必须实现其代码。

  我们做使用Junit工具来做单页测试或接口测试时,需要注意一些问题,包括我们的编码规范,test规范,以及编写测试代码的策略,以下个人的总结。

  1.为还没有实现的测试代码抛出一个异常。这就避免了该测试通过,而且会提醒你必须实现其代码。

  2.一次只测试一个对象。单元测试一个重要的方面就是细粒度,它独立的检查你创建的每个对象,这样你就可以在问题发生的第一时间就把它们隔离起来。如果测试多于一个对象,那么你就无法预测到这些对象发生了改变时它们会如何相互影响的。

  3.选择有意义的测试方法名。你应当能通过阅读方法名就可以理解要测试的是什么方法。一条好的规则就是一开始就遵守test_XX1_XX2的命名模式,其中XX1是待测方法名,XX2就是测试条件或目的。

  4.在assert调用中解释失败原因。无论何时,只要你用到assertTrue,assertFalse,assertNull,assertNotNull方法,请记住要使用第一个参数是String类型的那个方法,这个参数让你可以提供一个有意义的文本描述,在断言失败的时候,Junit TestRunner 会显示这个描述,若不使用这个参数,那么当测试失败时就比较难找出失败原因了。

  5.测试任何可能失败的事物。测试主执行路径很好,而且很需要做;但测试异常处理可能更重要。如果主执行路径出错,那么可能应用程序也无法工作。

  6.让测试改善代码。编写单元测试常常有助于你写成更好的代码。理由很简单,testcase是你的代码的用户,只有在使用代码的时候才能发现代码的缺点,所以应当根据测试时发现的不便之处重构代码,使其更易于使用。TDD就类似,通过先编写测试,再从代码用户的角度来开发你的类。

  7.让异常测试易读。把catch块中的异常变量命名为expected,这样就可以明确的告知读代码的人,这个异常是我们预期的,抛出异常才能让测试通过,在catch块中加入assertTrue(true)语句也进一步强调,这才是正确的执行路径。

  8.同一个包,分离的目录。把所有测试类和待测类都放在同一个包中,但使用平行目录结构,为了可以访问保护型的方法,需要把测试和待测类放在同一个包中,为了简化文件管理,并让人清晰的分辨测试类和开发代码类,所有需要把测试放在一个单独的目录中。当然我们也可以使用一个test的包,进行遗漏所有开发包。这样也可以把test需要的resources文件也可也独立起来。

  9.存在三种单元测试:逻辑单元测试,集成单元测试,功能单元测试。逻辑单元测试主要是检查代码逻辑性,通常只是针对单个方法,一般可以通过mock objects 和stub 来控制特定的方法的边界。集成单元测试主要是在真实环境下的一个组件相互交互的测试。功能单元测试目的是为了确认响应的结果是否正确,这种单元测试更多的依赖于外部环境。

  10.考察单元测试的覆盖率。一种方法就是数一下你的测试中用到了多少方法。使用Clover工具进行覆盖率统计,记住100%的测试覆盖并不能保证你的应用程序得到了100%的测试。

  11.测试先行。在写任何代码之前,必须先写一个失败的测试。为啥是失败的测试呢,因为不是失败的测试,老是成功的测试,你就不会改进这些代码来使其更加具有维护性。

原文转自:http://www.ltesting.net