目前我们的项目有超过 3000 个单元测试，“ant testAll”需要 20 多分钟。 除了获得更好的硬件，还有什么方法可以加快速度？
【问题讨论】：
标签： java performance unit-testing ant
我建议有两个构建（增量构建在每次签入时运行，完整构建在夜间运行）
增量版本在大约 7 分钟内运行较短的测试，而完整版本在不到 40 分钟的时间内运行所有测试。
Clearcase 确实鼓励了分支噩梦，但您应该能够为每个开发人员构建两个版本。我会质疑让每个开发人员都在自己的分支上开发的价值，因为我相信让开发人员在同一个分支上（成对或更多）一起工作会有一些好处。
注意：一台持续集成服务器可以有任意数量的代理，如果您负担不起一台以上的服务器，您可以使用 PC 作为构建代理。 （你必须至少有 30 个）
【讨论】：
您是否在junit 通话中使用fork="yes"？如果是这样，请确保设置forkMode="once"，否则 junit 任务将为每个 TestCase 类启动一个新 VM。有了 3000 个单元测试，这将产生巨大的影响。
【讨论】：
开始：
a) 获取有关 Junit 测试运行时间的统计信息。您可能已经在测试报告中获取了这些信息。
b) 取出前 10 个测试课程（按时间计算）并尝试减少时间。您需要持续进行此操作。
c) 尝试通过重构甚至改变测试方法来减少运行时间。
我遇到的一个这样的案例是在一个用于 CRUD 测试用例的测试类中。更新测试用例首先创建功能然后更新。但是我们已经在单独的测试用例中测试过创建。所以在这些情况下，您可以链接您的测试用例，例如
@Test()
public void testCreate() throws Exception
{}
@Test(dependsOnMethods = "testCreate")
public void testAmend() throws Exception
{}
@Test(dependsOnMethods = "testAmend")
public void testDelete() throws Exception
{}
因此，您可以省去重复测试。
d)我能够显着减少时间的另一个例子是。 我们有一个系统（inherietd），其中每个测试用例都调用 SetUp（Strating Spring Server 等）并在运行后关闭系统资源。这非常耗时，所以我重构它以在测试套件之前和整个套件之后启动 coomon 资源完成然后关闭它们。
e) 根据您的项目，它们可能是您可能需要解决的其他瓶颈。
【讨论】：
我假设您已经完成了所有其他常用步骤，例如模拟数据库调用、优化测试设置阶段等.
如果是这样，一种方法是多线程测试运行。Test-NG 非常支持这一点。将您的测试从 junit 转换为 test-ng 并不难，只需要完成一次。
可以轻松标记必须按顺序运行的测试：
@Test(sequential = true)
public class ATest {
...
在多核机器上，您会看到运行时的巨大改进。即使在单核上，您也会看到很好的改进，因为一些线程等待 io 操作。
有关如何设置的详细信息，请参见此处：
http://beust.com/weblog/archives/000407.html
希望这会有所帮助。
....
更多建议 - 我不敢相信您没有使用持续集成。相信我，30 名开发人员不会让你的 CI 服务器超载。即使您无法购买 CI，也可以在您自己的机器上安装 hudson - 设置需要 10 分钟，而且好处是巨大的。询问您的经理，每个开发人员都在等待单元测试完成或让服务器为您完成，哪个更糟糕。为破坏构建的人戴上一顶愚蠢的帽子通常足以说服开发人员运行他们的单元测试。
如果签入的质量确实是一个大问题（不要忘记签入总是可以回滚）考虑Teamcity - 它会运行测试并且如果测试失败则不会提交代码。
最后，一个可能适合您的用例的选项也是clover and bamboo。 最新版本会记录哪些代码由哪些测试进行测试，以及何时进行更改，它只运行相关测试。这可能非常强大。
但请记住，像 test-ng、teamcity 和 clover 这样的聪明工具只会让您走这么远 - 好的测试不会自己编写！
总结一下我的解决方案是尝试以下全部或部分步骤：
【讨论】：
与加速任何其他代码的方式相同。找出哪些测试花费的时间最多，并了解如何优化它们。
有很多操作可能会很慢，如果您执行 3000 次，就会累加起来。有时，在测试之间重用数据是值得的（即使您不应该在单元测试中这样做，如果这样做可以让您的测试以可接受的速度运行，那么这可能是必要的）。
为您的测试计时。通常，它们中的 90% 几乎会立即执行，而最后 10% 几乎会占用所有时间。找到那 10% 的人，看看他们在做什么。
通过探查器运行代码，并注意时间花在哪里。猜测是浪费时间。你认为测试运行者在做什么是没有意义的。 找出它在做什么，而不是猜测。然后你就会知道如何加快速度。
【讨论】：
一些想法：
【讨论】：
如果不进一步了解正在测试的内容，唯一容易呈现的两种方法是：
您甚至可能想在测试运行中运行分析器，看看是否有任何特别低效的测试实现。
【讨论】：
您可能希望将单元测试拆分为套件。您的应用程序是模块化的吗？您真正需要多久运行一次所有测试？如果您的开发人员只运行与他们自己的模块相关的单元测试，并且您在夜间和/或在 CI 上运行一系列测试，这是否可以接受？
是否有任何非常复杂的特定单元测试（我知道，我在这里滑入功能和集成测试，但这条线有时很模糊），但是它们中的任何一个都可以在 sanity-level 在开发过程中，然后在 CI 上用完？
编辑：为了好玩，我将简要描述一下我以前的一个项目中的测试例程
首先，测试系统的增长是有机的，这意味着它不是最初计划出来的，而是随着它的增长而修改和变化的。因此，它并不完美，而且随着时间的推移，一些命名约定已成为杜撰。
自动测试 - 这是笨蛋的疯狂。
【讨论】：
显然你的测试中有一些东西需要很长时间。
有时，您无法绕过缓慢的测试。例如，测试 Spring 是否可以读取其所有配置文件，测试 hibernate 映射是否有效，诸如此类。这些测试的好处是它们只需要在一个测试中运行，然后你可以全部模拟出来，但你也可以决定将它们作为集成测试的一部分运行，让构建服务器担心它。
其余的测试很慢，要么是因为它们正在执行 IO，要么是因为它们过度占用 CPU。
IO 可以是很多东西。 Web 服务和数据库调用可以被抽象出来和模拟，如果需要的话，你必须做的几个真正的调用可以移动到集成阶段。日志记录也可以真正减慢速度——尤其是 3.000 个测试用例。我想说的是完全关闭日志记录，并在测试失败时依靠你的大脑和调试器。
在某些情况下，IO 本身就是被测试的单元。例如，如果您正在测试将表数据写入磁盘的数据库服务器部分。在这种情况下，尽量在内存中保留尽可能多的 IO。在 Java 中，许多 IO 抽象都有内存实现。
CPU 边界测试也有不同的风格。纯性能和吞吐量测试应该在集成测试阶段。如果您正在启动一堆线程来尝试检查并发错误，那么您可能会将大型测试移至集成阶段，并在您的常规测试套件中保留一个“轻量级”版本。
最后，分析器是你的朋友。很可能您的部分代码可以变得更有效率，并显着加快您的测试速度。
【讨论】：
好吧，我不知道你的单元测试在做什么，但你需要问自己为什么它需要 20 分钟。 根据我的经验，通常有很多测试在几毫秒内运行，而剩下的所需时间很少。大多数情况下，这些测试涉及 IO/network/DB-Stuff。 例如，如果您因网络延迟而花费大量时间等待，则可以考虑并行运行测试。
您可以搜索这些测试并寻求改进。但是让你的测试更快并不会让你的实际代码更好。 您可能要注意需要大量时间的测试，因为被测类不是最佳的。查明和改进此类情况很可能也会使您的产品更好/更快。
【讨论】：
我同意巴勃罗吉姆的观点。并行化您的测试。我们正在使用 clearcase 并从视图服务器传输所有内容确实减慢了速度。当我们在 Duelcore 上进行并行化时，我们得到了 6-8 倍的更短测试运行速度。
我们正在使用 CPPUnit 框架，并且我们刚刚添加了一个 python 脚本来在不同的线程上启动不同的测试套件。
我们还使用 clearmake 来并行化构建过程。我们的下一步可能是在开发人员的客户端上并行化测试。
【讨论】：
在连续集成引擎系统中移动完整的测试套件，因此开发人员不必每次都运行它们。这样的系统比开发者更有耐心。
【讨论】：
我会像解决任何其他性能问题一样解决这个问题：
您可能会发现最终必须深入研究该测试运行程序。您可以使用像cavaj 这样的反编译工具从类文件中生成源代码（虽然它显然比原始代码更难阅读）。您可能会发现测试运行器实现中的某些内容正在影响性能。例如，您已经提到读取 XML 配置文件作为测试运行程序执行的一项活动——这可能会影响性能。
您最终可能会发现性能问题的另一个领域是自定义“基础”测试用例类。这些往往会增加很多便利性，但很难记住您的便利性添加行为可能会在一个大型项目中分摊到 10k 次测试中，无论每个测试是否需要便利行为。
【讨论】：
这是我将采取的方法。
【讨论】：
加速大型测试套件的最有效方法是逐步运行它，以便仅重新执行自上次测试运行以来涉及代码更改的测试。毕竟，最快的测试总是那些没有执行的。 8^)
困难的部分实际上是让它发挥作用。我目前正在为 JUnit 4 进行增量测试，它是 JMockit 开发人员测试工具包中“JMockit Coverage”工具的一部分。虽然还不成熟，但我相信它会很好用。
【讨论】：
数据库访问和网络延迟可能是需要检查的领域。如果您在集成测试中执行大量数据库访问，您可能想要探索使用像 HSQL、H2 或 Derby 这样的内存数据库，而不是像 Oracle 这样的“真实”数据库。如果您使用的是 Hibernate，您还必须更改 Hibernate 配置中的设置以使用特定于该数据库的方言（例如，HSQLDialect 而不是 OracleDialect）。曾经在一个项目中，每个完整构建最终都必须删除并重新创建整个 Oracle 模式并通过网络执行大量数据库测试，有时需要长达 20 分钟，然后你发现有人签入并且事情被破坏了再次。 :(
理想情况下，您只希望有一个可用于两个数据库的数据库脚本，但您最终可能不得不同步两个不同的数据库创建脚本 - 一个用于生产，一个用于集成测试。
同一 JVM 中的数据库与跨网络的数据库 - 可能会有所不同。
【讨论】：