更好的单元测试

原文Better Unit Tests
作者:Manu Pk 翻译:赖信涛 责编:仲培艺

在过去的几年间,我们向我们的产品中加入了很多单元测试,提高内部质量。在此期间,我们经常遇到选择单元测试还是一体化测试的困难。我想介绍一些我们用以优化现有系统的方法。

单元测试的核心是,隔离组件的依赖,每次测试一个单独的组件。经典的单元测试有这些原则:“快速,独立,可重复,自我验证,及时。”在Java中,一个方法就是一个单元。所以,传统的(也是最常用的)单元测试是将类的每个方法和他们的依赖分来,分别测试。

有趣的是,一个单元是什么,并没有明确的定义。很多时候,跨多个类的多个方法的组合可能有相同的行为。所以,在这种情况下,这种行为可以视作一个单元。我见过很多人打破单元,去单独测试每一个方法。如果中间结果对我们来说没有意义,这样做只会让系统更加复杂。最好的方法是和他们的依赖一起测试。所以,我们要结合它们的实现来测试,而不只是模仿。Bob大叔在这篇文章中说:“模仿要突破边界。”

如果软件是用TDD方法开发的,那么脱离依赖,或者向下一个特性添加测试就不是一个难题了。但是,不是所有的软件都用这种方法。更不幸的是,有一些系统只写了很少的测试,甚至没有写测试。这种情况下,我们就可以在不同的层级使用这些测试的原则。Terry Yin在他的演讲“测试的错误概念”中给了我们下面这张图,展示了不同测试的优点和缺点。

很多项目都用了Java和Spring框架。我们使用了Spring的@RunWith和SpringJUnit4ClassRunner,可以创建带有依赖的对象。如果有需要,你可以有选择地模拟依赖。使用这个平台,可以轻松地写出带有依赖的测试对象。我们称它为app层测试。这也是一种没有外部依赖的快速运行测试。我们也有可以连接外部系统的一体化测试。现在,我的默认测试选择都是app层测试,只有在写逻辑很复杂的代码时,才会使用单元测试。

2016年8月12-13日由CSDN主办的SDCC 2016架构&运维峰会将在成都站召开,5人以上团购或者购买两场峰会通票更有特惠,余票不足,预购从速。(票务详情链接)。
更多详细内容参见官网网址:SDCC数据库&架构峰会成都站大会报名

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/joy0921/article/details/80124731
上一篇Linux基金会承接Open vSwitch虚拟网络项目
下一篇盘点最受欢迎的十个开源大数据技术
想对作者说点什么? 我来说一句

JUnit4使用

2013年08月01日 627KB 下载

单元测试覆盖率单元测试覆盖率

2011年02月11日 15.26MB 下载

没有更多推荐了,返回首页

关闭
关闭