JUnit测试类顺序 [英] JUnit test class order

问题描述

我有一个带有Maven的Java应用程序. Junit用于测试，带有故障安全和surefire插件. 我有2000多个集成测试. 为了加快测试的运行速度，我使用了故障安全jvmfork来并行运行测试. 我有一些繁重的测试类，它们通常在测试执行结束时运行，这会减慢我的CI验证过程. filesafe runorder:balanced对我来说将是一个不错的选择，但由于jvmfork，我无法使用它. 重命名测试类或移动到另一个软件包并按字母顺序运行它不是一种选择. 有什么建议可以在验证过程开始时运行慢速测试类吗?

I have a java app with maven. Junit for tests, with failsafe and surefire plugins. I have more than 2000 integration tests. To speed up the test running, I use failsafe jvmfork to run my tests parallel. I have some heavy test class, and they typically running at end of my test execution and it is slows down my CI verify process. The filesafe runorder:balanced would be a good option for me, but i cant use it because the jvmfork. To rename the test classes or move to another package and run it alpahabetical is not an option. Any suggestion how can I run my slow test classes at the begining of the verify process?

推荐答案

在提供建议之前，让我总结一下所有内容.

Let me summarize everything before I will provide a recommendation.

1. 集成测试很慢.很好，这很自然.
2. CI构建不会运行假设已部署系统的测试，因为CI中没有部署.我们关心CD过程中的部署. 因此，我假设您的集成测试不进行部署.
3. CI构建首先运行单元测试.单元测试非常快，因为它们仅使用RAM.
   我们从单元测试中获得了良好而快速的反馈.

1. Integration tests are slow. This is fine and it's natural.
2. CI build doesn't run tests that assume deployment of a system, since there is no deployment in CI. We care about deployment in CD process. So I assume your integration tests don't assume deployment.
3. CI build runs unit tests first. Unit tests are extremely fast because they use only RAM.
   We have good and quick feedback from unit tests.

此刻，我们确信获得快速反馈是没有问题的.但是我们仍然想更快地运行集成测试. 我将建议以下解决方案:

At this moment we are sure we don't have a problem with getting a quick feedback. But we still want to run integration tests faster. I would recommend the following solutions:

1. 改进实际测试.通常，它们并不有效，并且可以大大加快速度.
2. 在后台运行集成测试(即不要等待它们的实时反馈).
   他们自然比单元测试要慢得多.
3. 将集成测试分为多个组，如果需要更快地从其中一些反馈，则分别运行它们.
4. 在不同的JVM中运行集成测试.同一JVM中没有不同的线程！
   在这种情况下，您不必关心线程安全，也不必关心线程安全.
5. 在不同的计算机上运行集成测试，依此类推.

1. Improve actual tests. Quite often they are not effective and can be speed up significantly.
2. Run integration tests in background (i.e. don't wait for real time feedback from them).
   It's natural for them to be much slower than unit tests.
3. Split integration tests on groups and run them separately if you need feedback from some of them faster.
4. Run integration tests in different JVMs. Not different threads within the same JVM!
   In this case you don't care about thread safety and you should not care about it.
5. Run integration tests on different machines and so on.

我处理了许多不同的项目(其中一些项目的CI构建运行了48小时)，而前3个步骤就足够了(即使是疯狂的情况).很少需要对步骤4进行良好的测试.步骤#5适用于非常特殊的情况.

I worked with many different projects (some of them had CI build running for 48 hours) and first 3 steps were enough (even for crazy cases). Step #4 is rarely needed having good tests. Step #5 is for very specific situations.

您看到我的建议与过程有关，而不与工具有关，因为问题出在过程中.
人们经常忽略根本原因并尝试调整工具(在这种情况下为Maven).他们获得了外观上的改进，但是所创建解决方案的维护成本很高.

You see that my recommendation relates to the process and not to the tool, because the problem is in the process.
Quite often people ignore root cause and try to tune the tool (Maven in this case). They get cosmetic improvements but with high maintenance cost of created solution.

这篇关于JUnit测试类顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！