Maven - 在JUnit测试之前将webapp部署到tomcat

Mic*_*man 36 junit tomcat maven-2 maven tomcat7

我有webapp,提供Web服务.我想用SoapUI执行JUnit测试以检查此服务是否正常工作.
但要测试Web服务应用程序必须部署到我的Tomcat 7服务器.

我不知道如何配置maven来构建war,然后将其部署到tomcat(理想情况下:为此运行单独的tomcat实例)然后运行JUnit测试.
我将不胜感激任何帮助.

我正在使用maven 2.2.1

Ste*_*lly 118

关于如何使用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(哦看,它更短更容易打字...奖金)

因此,您可以执行以下操作:

对于额外的布朗尼点,您可以使用build-helper-maven-plugin:reserve-network-port绑定到validate阶段,以确保测试服务器在未使用的网络端口上启动,然后对测试资源使用资源过滤来传递端口到测试或使用通过systemPropertyVariables传递的系统属性,使端口号可用于测试.

好处

  • 清洁Maven构建
  • 如果测试失败,则无法释放项目
  • run-its如果测试速度太慢而无法运行每个构建,可以将集成测试移动到单独的配置文件中(按照惯例调用).

缺点

  • 很难从IDE运行测试.所有集成测试都开始/结束IT,而Maven知道在TestSurefire中运行测试开始/结束并IT使用Failsafe 运行测试开始/结束,您的IDE可能不会.此外,您的IDE不会为您启动容器,因此您必须手动执行大量工作才能实际运行测试.
  • 调试测试可能需要附加两个调试器,例如一个调试在容器中运行的应用程序,另一个调试测试用例.

    mvnDebug -Dmaven.failsafe.debug=true verify
    
    Run Code Online (Sandbox Code Playgroud)
  • 将您的测试与Maven构建过程相结合.

学校2 - 单独的模块

这种思想将集成测试移动到一个独立的模块中,该war模块依赖于模块并使用复制war到测试资源中,例如dependency:copy-dependencies绑定到generate-test-resources与Tomcat7依赖关系相结合的阶段进行测试.

测试用例本身使用嵌入模式启动Tomcat7容器

好处

  • 测试可以在IDE中运行
  • 集成测试与单元测试分开,因此要求IDE运行所有测试不会启动较慢的测试

缺点

  • war,如果你走过去的神器只是重建package阶段,因此,你需要至少运行mvn clean package定期使用IDE时刷新被测代码.
  • 集成测试的失败不会破坏war模块的构建,因此您最终可能会释放损坏的war工件,然后使集成测试模块的reactor构建失败.有些人通过在集成测试模块中src/it使用Maven Invoker插件来运行测试来抵消这个问题......虽然这提供了较差的IDE集成,所以我不推荐这一行.
  • 很难从Maven获得一份综合的测试报告.
  • 必须在测试用例中对容器的启动/停止进行编码.

School 2.5 - 测试用例启动自己的Tomcat7服务器时出现故障

这是两种方法的混合体.

您使用Failsafe来执行测试,但测试本身负责启动和停止您要测试的Tomcat7容器.

好处

  • 不必在Maven pom中配置服务器启动/停止
  • IDE可以安全地运行所有测试(尽管集成测试可能会更慢并且您可能不想运行它们,但它们并不像它们都会失败,除非测试失败)
  • 更容易从IDE调试测试(只有一个要附加的进程,IDE通常可以通过提供特殊的测试运行器来轻松调试测试)

缺点

  • 必须在测试用例中对容器的启动/停止进行编码

我希望上面的内容可以帮助您了解您的选择.可能还有其他调整,但总的来说,上面被认为是目前与Maven进行集成测试的最佳实践.

  • 这是美丽的回应.可惜我只能给一个upvote ;-) (6认同)
  • +1我在一段时间内看到过的最佳答案之一. (4认同)
  • 故障安全和集成测试/验证加上Eclipse:在我们的例子中,我们通常从Eclipse本地运行我们的app服务器,并在我们的集成测试中使用注释`@RunWith(SpringJUnit4ClassRunner.class)`,这似乎足以让Eclipse认可我们的单元测试. (3认同)