Maven：手动测试的源文件夹答案

【问题标题】：Maven: Source folder for manual testsMaven：手动测试的源文件夹
【发布时间】：2014-05-28 10:33:46
【问题描述】：

我想在 Eclipse 中有一个源文件夹，它被视为测试源，但在测试阶段被忽略。它将包含单元测试和其他只能手动执行的代码。

它必须在 eclipse 中作为源文件夹出现并编译
它必须使用具有测试范围的依赖项进行编译
它将包含单元测试
这些单元测试不得在 Maven 生命周期的任何阶段执行
不得将代码打包为构建的一部分
我还有一个用于单元测试的源文件夹，它将在测试阶段执行

这可能吗？如果可以，怎么做？

【问题讨论】：

这是一个额外的测试文件夹。我已经使用了构建助手，因为我认为我需要它以便为测试提供第二个源文件夹
重新考虑后删除了我的最后一条评论。如果您继续使用正常的测试目录但以不同的方式排除那些手动测试，您可能会发现您的生活更轻松。例如。请参阅Is there a way to tell surefire to skip tests in a certain package? 作为替代方案。或者考虑故障安全插件是否是更好的选择（即将它们视为集成测试）。
基于包跳过测试类似于我想要实现的目标，但我真的希望能够基于源文件夹跳过
我认为这行不通，除非我可以将源文件夹编译到不同的目标目录
将文件夹添加到 Eclipse 构建路径似乎效果很好，但令人沮丧的是，这会增加手动配置项目的步骤

标签： java eclipse unit-testing maven junit

【解决方案1】：

Maven 旨在强制您使用标准项目设置。虽然有些偏差是可能的，但有时最好看看解决问题的标准方法。

几个解决方案：

将项目拆分为多个模块。您可以将所有此类测试移动到一个新模块中。在 Eclipse 中，您只需导入所有模块。在 Maven POM 中，默认配置文件不包含新模块。 Eclipse 可以记住您希望为项目激活哪些配置文件，因此您可以通过静态配置获得不同的行为。
使用 JUnit.Assume。简而言之，Assume 中止测试而不使其失败。它有点像@Ignore。所以混合测试，但将此行添加到您只想手动运行的所有测试中：
```
Assume.that(Boolean.getBoolean("runManualTests"));
```
您现在可以通过将 -DrunManualTests=true 添加到 VM 参数来运行这些测试。 Eclipse 允许您导出启动配置，以便您可以创建一对并将它们放入您的项目中以轻松运行测试。
解决阻止您始终运行所有测试的潜在问题。他们太慢了？使用 CI 服务器。它们很脆吗？好吧，让他们更稳定。为此，我需要进一步了解您的具体原因。

【讨论】：

我同意：这些都是好方法。我还将手动测试提取到一个单独的模块中，但这可能并不总是可行的。 CI 也是进行这些测试的好地方。
如果一切都失败了，那么您可以将其他测试打包到一个 JAR 中，并将它们添加为带有分类器 tests 的依赖项。这将使代码对新模块可见。
我认为使用模块是一个非常好的解决方案。由于我不愿承认的原因（我将在 eclipse 中手动将文件夹添加到构建路径），它对我来说并没有真正起作用，但我觉得这是最好的解决方案

【解决方案2】：

Maven Surefire Plugin 是在构建期间运行测试的插件。根据inclusions and exclusions documentation ...

默认情况下，Surefire 插件会自动包含所有具有以下通配符模式的测试类：

- "**/Test*.java" - includes all of its subdirectories and all java filenames that start with "Test".
- "**/*Test.java" - includes all of its subdirectories and all java filenames that end with "Test".
- "**/*TestCase.java" - includes all of its subdirectories and all java filenames that end with "TestCase".

因此，您可以轻松编写不遵循上述模式的测试类，但仍将它们放入src/test/java 目录。在任何 IDE 中，这意味着他们可以像其他人一样访问（测试）构建路径，并且可以从该 IDE 轻松执行它们。但它们不是由 Maven 执行的。

【讨论】：

我可以看到这可行，但引入命名约定并不理想，因为它可能难以沟通。我认为从长远来看这会导致问题
@Edd Maven 是关于命名约定的，Surefire 也不例外。使用命名模式完全符合 Maven 哲学。（命名模式可能会导致问题，例如，如果某些其他插件碰巧使用与您相同的命名模式。我不知道src/tst 文件夹中的任何内容，所以对于这个特定的问题应该没问题。 )

【解决方案3】：

我认为您从错误的角度看待它。如果我是你，我会创建一个<profile/> 并在maven-surefire-plugin 的（配置文件的）设置中定义*My*Test 应该在激活此配置文件时执行。实际上，我会创建两个单独的配置文件——一个是<activeByDefault/>（这将排除My*Test，并且只有在没有从命令行指定<property/>时才被激活）；以及另一个基于属性的带有<activation/> 的配置文件——例如，您将通过传入-Dmy.test.property 手动触发此配置文件。这样您就可以避免使用 build-helper-maven-plugin 的所有黑魔法。

【讨论】：

我不认为使用这种方法该文件夹会在eclipse中显示为源文件夹
我的建议是：将“手动”测试放在src/test/java 下，但要确保它们匹配某种独特的模式，例如“*ManualTest.java”。这样，代码仍将被视为源代码并位于适当的位置。另外，src/test/java 下的代码无论如何都不会进入最终工件。
*ManualTest.java 仍将触发 Surefire 的“在此文件中查找测试”机制，因此应使用不同的命名约定。