如何编写好的测试

为我们的软件编写测试是非常好的一件事。但事实上，目前为止，编写好的测试有时候同样重要。
通过以下一些偏执的原则，让我们将测试写的更加完美吧:

保持测试代码紧凑易读

要做到这一点，请像对待生产代码一样，有时候请毫不犹豫重构它。否则，在测试端会产一些腐坏的代码，就像在测试端创建了可怕的遗留代码。如果测试不容易重构，那么生产代码也很难重构，从而导致在生产环境产生遗留的代码。请让我们变成一个勇敢的重构者。

避免啰嗦的代码

例如，测试代码多次使用某个在一个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一种他们不拥有的类型时，他们精力过的痛苦：

不要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" 这本书

这本书是必读的。它讲述了如何从一个一无所有应用变成了一个功能齐全的应用程序。作者解释了开发的许多方面，以及如何在项目生命周期的各个阶段实现测试。

如何编写好的测试 with Mockito