关于如何使用 Maven 处理这种类型的集成测试,存在多种思想流派。
我应该指出,当您将应用程序部署到应用程序服务器时,您不再处于单元测试领域。因为整个应用程序都部署在一个容器中,所以您正在测试这两个组件的集成。
现在使用 JUnit 运行 集成测试 没有任何问题(尽管您可能会遇到一些限制,例如 单元测试 不应该关心排序单个测试 - 假设您正确编写它们 - 所以 JUnit 通过不保证任何执行顺序来强制执行 ...在 Java 1.7 之前,执行顺序意外地被测试方法的顺序所暗示类,但它不是 JUnit 合同的一部分...如果他们发现 单元测试焦点,有些人会切换到其他测试框架进行 集成 测试,例如 TestNG的 JUnit 正在妨碍他们的测试开发)
要记住的关键点是 Maven 生命周期使用test 阶段来执行单元测试。
对于集成测试,关于使用 Maven 处理测试的正确方法有两种(半)思想流派。
学校 1 - 故障安全和integration-test/verify
这种思想流派使用package之后的阶段来启动容器,运行集成测试,拆除容器,最后检查测试结果并在测试失败时使构建失败。
永远不要运行mvn integration-test,因为这不会正确地拆除容器,任何时候你想输入mvn integration-test你实际上想输入mvn verify(哦,看,它更短更容易还要输入...奖金)
因此,您可以执行以下操作:
对于额外的加分,您可以使用绑定到validate 阶段的build-helper-maven-plugin:reserve-network-port 来确保测试服务器在未使用的网络端口上启动,然后对测试资源使用资源过滤将端口传递到测试或使用通过systemPropertyVariables 传递的系统属性使端口号可用于测试。
优势
- 干净的 Maven 构建
- 如果测试失败,您将无法发布项目
- 如果测试太慢而无法运行每个构建,则可以将集成测试移动到单独的配置文件中(按照约定称为
run-its)。
缺点
学校 2 - 独立模块
这种思想流派将集成测试移动到一个单独的模块中,该模块依赖于 war 模块,并将 war 复制到测试资源中,例如dependency:copy-dependencies 绑定到 generate-test-resources 阶段以及要测试的 Tomcat7 依赖项。
测试用例本身使用embedded mode启动Tomcat7容器
优势
- 测试可以在 IDE 中运行
- 集成测试与单元测试分开,因此要求 IDE 运行所有测试不会启动较慢的测试
缺点
-
war 工件只有在您超过 package 阶段时才会重建,因此,在使用 IDE 时,您需要至少定期运行 mvn clean package 以刷新被测代码。
- 集成测试的失败不会破坏
war 模块的构建,因此您最终可以释放一个损坏的war 工件,然后让集成测试模块的反应器构建失败。有些人通过在 src/it 中使用集成测试模块并使用 Maven Invoker 插件来运行测试来解决这个问题......虽然这提供了较差的 IDE 集成,所以我不推荐该行。
- 很难从 Maven 获得综合测试覆盖率报告。
- 必须在测试用例中自己编写容器启动/停止代码。
School 2.5 - 测试用例启动自己的 Tomcat7 服务器的故障保护
这是两种方法的混合体。
您使用 Failsafe 执行测试,但测试本身负责启动和停止您要测试的 Tomcat7 容器。
优势
- 不必在 Maven pom 中配置服务器启动/停止
- IDE 可以安全地运行所有测试(尽管集成测试可能会比较慢,您可能不想运行它们,但除非测试失败,否则它们不会全部失败)
- 更容易从 IDE 中调试测试(只需附加一个进程,IDE 通常会通过提供特殊的测试运行程序来轻松调试测试)
缺点
我希望以上内容可以帮助您了解您拥有的选项。可能还有其他调整,但总的来说,以上被认为是目前与 Maven 进行集成测试的最佳实践。