转载

更好的单元测试

原文： Better Unit Tests

作者：Manu Pk 翻译：赖信涛责编：仲培艺

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

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

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

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

更好的单元测试

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

有关测试方面的内容，大家可以访问 CSDN知识库——软件测试，里面有非常全面的资源和学习资料。更好的单元测试