返回 登录
0

更好的单元测试

原文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数据库&架构峰会成都站大会报名

评论