如何编写好的测试
为我们的软件编写测试是非常好的一件事。但事实上,目前为止,编写好的测试有时候同样重要。
通过以下一些偏执的原则,让我们将测试写的更加完美吧:
保持测试代码紧凑易读
要做到这一点,请像对待生产代码一样,有时候请毫不犹豫重构它。否则,在测试端会产一些腐坏的代码,就像在测试端创建了可怕的遗留代码。如果测试不容易重构,那么生产代码也很难重构,从而导致在生产环境产生遗留的代码。请让我们变成一个勇敢的重构者。
避免啰嗦的代码
例如,测试代码多次使用某个在一个parser被使用的regexp 生成某些东西 。
一般来说,人们不想在测试和代码之间复制逻辑。因此,在测试中复制生产代码regexp或其他东西不是一个好的选择。在这种情况下,考虑测试“输入刺激”/“输出结果”有助于(f(input) -> output),例如,如果某段代码假定处理模板,则不要带入value。所以,请根据计算结果进行测试。
// use
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo("this is 'param1', and this is 'param2'"));
// instead of
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo(String.format("this is '%s', and this is '%s'", param1, param2));
尽可能大的提高覆盖度,以展示正确尤其是错误的代码情况
通常,在实践测试驱动开发时,这是最好的实现方法。有了TDD,人们可以在设计时识别出什么可能会被破坏。不要羞于为一件小事编写一个简单的测试用例。您永远不知道何时、为什么或如何使用或修改此代码。
一个可以用来检查测试有效性的范围区域的方法是使用PIT等工具进行突变测试。
不要mock你不拥有的对象类型
这不是一条硬指标线,但跨越这条线可能会产生恶果!(很可能会)
TDD和测试一样重要,当模拟外部API时,测试无法用于驱动设计,API属于其他人;第三方可以并且将更改API的签名和行为。
想象一下mock第三方lib的代码。在第三个库的特定升级之后,逻辑可能会发生一些变化,但是测试套件执行得很好,因为它是模拟出来的。所以后来,我们认为一切正常运作,我们开始软件部署上线,但是…BOOM,我们可能得去51Job 看看了。
这可能是当前设计与第三方库的耦合不够的迹象。
另一个问题是,第三方库可能很复杂,甚至需要大量的模拟才能正常工作。这导致了得使用过度指定的测试和复杂的组件,而这损害了测试本身紧凑和可读性的目标。或者对代码覆盖不够的测试,由于模拟外部系统的复杂性,导致了测试的覆盖度不够的问题。
因此,最常见的方法是为外部lib/系统创建包装器,尽管应该注意抽象泄漏的风险,因为太多的低级API、概念或异常超出了包装器的边界。为了验证与第三方库的集成,编写集成测试,并使它们尽可能紧凑和可读。
有些人已经写过这件事,当mock一种他们不拥有的类型时,他们精力过的痛苦:
- http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html
- http://www.markhneedham.com/blog/2009/12/13/tdd-only-mock-types-you-own
- http://blog.8thlight.com/eric-smith/2011/10/27/thats-not-yours.html
- http://stackoverflow.com/questions/1906344/should-you-only-mock-types-you-own
不要mock一切东西,毕竟他是反模式的
如果一切都是模拟的,我们真的在测试生产代码吗?不mock 时尽量不mock!
不模拟值对象
为什么会有人想这么做?
因为实例化对象太痛苦了!?=>这真的不是一个正当的理由。
如果创建新的fixture太困难,这就表明代码可能需要一些比较厉害的重构。另一种选择是为您的值对象创建构建器——这有一些工具,包括IDE插件、Lombok和其他。还可以在测试类路径中创建有意义的工厂方法。
fixture 概念参见 这里
abstract class CustomerCreations {
public static Customer customer_with_a_single_item_in_the_basket() {
// long init sequence
}
}
Mockito关注的是对象之间的交互,这是面向对象编程(或消息)最重要的部分。
阅读 "Growing Object Oriented Software Guided by Tests" 这本书
这本书是必读的。它讲述了如何从一个一无所有应用变成了一个功能齐全的应用程序。作者解释了开发的许多方面,以及如何在项目生命周期的各个阶段实现测试。