用 JUnit 编写系统测试

Question

前言

我故意谈论系统测试。我们确实有一套相当详尽的单元测试，其中一些使用模拟，而那些不会去任何地方。系统测试应该是对单元测试的补充，因此模拟不是一种选择。

问题

我有一个相当复杂的系统，它只通过 REST 和 websocket 事件进行通信。 我的团队有相当多的（历史发展的）基于 JUnit 的系统测试。 我目前正在将此代码库迁移到 JUnit5。

测试通常由@BeforeAll 组成，其中系统以特定于测试类的配置启动，大约需要一分钟。然后对这个系统进行了一些独立的测试。

我们经常遇到的问题是引导系统需要相当长的时间，甚至可能会失败。可以说引导本身可以被认为是一个测试用例。 JUnit 处理生命周期方法有点奇怪——报告中没有显示它们所花费的时间；如果他们失败了，它就会影响测试的数量；它不是描述性的；等等

我目前正在寻找一种解决方法，但我的团队在过去几年所做的工作与 JUnit 的核心理念有些正交（因为它是一个单元测试框架）。

如果我将@BeforeAll 替换为测试方法（我们称之为@Test public void boot(){...}）并引入强制boot 运行的顺序依赖性（使用JUnit 5 很容易），这些问题就会消失在运行任何其他测试之前。

到目前为止一切顺利！这看起来和工作得很好。当测试不是由 CI 服务器执行，而是由试图排除故障的开发人员执行时，实际问题就开始了。当我尝试启动单个测试时，boot 从测试执行中被过滤掉，测试失败。

在 JUnit5 中有什么解决方案吗？还是我应该采取完全不同的方法？

我怀疑使用@TestTemplate 可能有解决方案，但我真的不确定如何继续。同样 afaik 只允许我生成新的命名测试，这些测试也会被过滤。我必须编写自定义测试引擎吗？这似乎并不令人信服。

Answer 1

这个更普遍的测试问题与 Junit5 相关。为了跳过很长的启动过程，如果可能的话，您可以模拟一些组件。将引导系统作为测试没有意义，因为还有其他测试依赖于此。在这种情况下最好像以前一样使用@beforeAll。对于测试启动，您可以为完全独立于其他测试运行的测试类创建单独的测试类。 另一种选择是将这种测试分组并与普通单元测试分开并仅在需要时运行它（例如在 CI 服务器上部署之前）。这实际上取决于特定的用例，并且这些测试是否应该成为您本地机器上常规构建的一部分。

第三个选项是尽可能减少启动时间。如果您不能使用模拟/存根或从常规构建中排除这些测试，这是一个选项。