Maven文件夹布局：我应该在EAR或其子模块中放置测试吗？
我们有一个包含多个子模块的EAR项目（多个EJB，Web项目，应用程序客户端等）。 单一测试的自然范围是它们各自的子模块（因为它们应该是测试隔离单元）。
在很短的时间内，我们引入了非显而易见的测试依赖项。 项目正在嘲笑其他项目的function等。很快我们的架构演变成了几个带有模拟的独立jar文件（web项目1模拟，ejb 2模拟等）; 我们将这些嘲讽与EAR连接起来并消耗子模块中的模拟（“Skinny War”风格）。
EAR Modules WEB 1 WEB 2 EJB 2 EJB 3 etc Libs Shared library 1 Shared Library 2 Testing dependencies WEB 1 mocks WEB 2 mocks EJB 1 mocks EJB 2 mocks etc WEB1 Uses EJB 1 and EJB 3 Uses Shared Library 1 Testing Consumes EJB 1 and EJB 2 mocks 无论如何，我们团队的共识是模拟失控。 我们希望向Arquillian发展并在容器内部进行测试（例如，向集成测试）。 我们还介绍了ATTD（最初只是使用Drone进行function测试，但我希望尽快安装function齐全的Thucydidies + JBehave或EasyB）。
测试可能取决于来自多个子模块的资源。 ShrinkWrap可以保证事情不会失控。
所以我的问题是： 我应该在哪里放置测试，故事，Arquillian配置文件等等？
我觉得EAR是分组一切的最佳场所：
EAR Modules Test src Java Test 1 Test 2 Resources Configuration Files Stories Story 1 Story 2
这将允许我们有一个统一的报告，忘记模块间的依赖关系，有一个单一的配置点等等。
但我可能错了（使用每个模块的粒度有其优点）。
那么Arquillian测试的最佳实践是什么：我应该将我的测试文件放在EAR项目中吗？ 我应该在EAR项目中进行集成/验收测试吗？在子模块中进行单一测试吗？ 或者我应该把所有东西都放在子模块中？
更新：替代方法。 我应该将集成测试隔离到单独的模块中吗？ 如果是，如何（我应该如何设置依赖关系，配置Arquillian等）？
让我提供一些关于如何与Maven组织集成测试的实用信息，以便其他人可以使用它来做正确的事情。
我最终接受了来自Maven以及Codehaus Maven和集成测试指南的出色建议（即使有点旧）的建议 。
-
使用聚合器顶级项目：
myproject myproject-ear myproject-war myproject-ejb ... myproject-integration-tests -
正如mchamati所建议的那样 ，让每个模块都使用unit testing进行测试（就像之前一样）。 unit testing很快，可以在每个构建上运行。
- 同样对于unit testing，事实certificate我最初的策略并不是那么糟糕。 我仍然有几个模拟模块绑定到EAR作为托管依赖项。
-
有一个单独的集成测试模块，其包装类型可以是pom; （你不会在这个项目中构建一个真正可部署的工件;而且，当测试数量开始增长时，将它转换为另一个聚合器pom可能是有意义的）：
myproject com.mycompany 1.0-SNAPSHOT 4.0.0 com.myproject myproject-integration-tests 1.0-SNAPSHOT pom -
遵循Maven约定集成测试应该进入
src/it：src/it org.apache.maven.plugins maven-compiler-plugin 3.1 1.7 1.7 testCompile -
使用failsafe运行集成测试：
org.apache.maven.plugins maven-failsafe-plugin 2.17 ${project.build.sourceEncoding} org.apache.maven.surefire surefire-junit47 2.17 integration-test verify -
让集成测试项目导入ear项目依赖项（以及您需要的所有其他内容）。 我不确定这是否被认为是好的做法，因为它没有在任何指南中提及，但它对我来说非常好。
com.mycompany my-project-ear 1.0-SNAPSHOT pom -
在集成测试模块中集中arquillian相关配置：
org.jboss.arquillian arquillian-bom ${arquillian.version} import pom junit junit 4.11 test org.jboss.arquillian.junit arquillian-junit-container ${arquillian.version} test -
遵循测试文件的故障安全命名约定 。
src/it/java com/mycompany/myproject mypackage MyIT.java MySecondIT.java anotherpackage YetAnotherIT.java -
利润
在顶级聚合器项目下：
-
mvn test运行充满嘲讽的快速unit testing -
mvn verify运行真正的集成/function/验收测试（可能很慢）
-
额外提示：如果您正在运行诸如Jenkins之类的CI服务器，请设置每晚构建以运行集成测试（即，让您的构建调用mvn verify ）。 不要将未经validation的构建部署到认证或生产服务器。
我曾经遇到过同样的问题，这更像是一个建筑问题，CBD（基于组件的开发）。 由于你有子模块，我更喜欢调用组件，他们应该测试自己（unit testing），它们之间的依赖关系不应该是循环的。 共享配置，以避免重复，可以是一个称为垂直组件的分离组件（在许多组件之间共享，更多地分类为“util组件”而不是“业务组件”）。 报告组件通常不依赖于它们，而是EAR，它是“最终节点”，因此报告组件将取决于许多组件。
我不确定我是否回答了您的需求，但在我看来，这是您的问题的根本原因，我曾经面对并解决了重新设计组件依赖关系树的问题。
对Arquillian我无能为力，但CBD的概念是组件（子模块）是自给自足的，他们必须做他们需要做的一切，甚至是测试和模拟数据。 您必须找到解决此架构问题的方法，例如，Maven Dashboard可能可以帮助您统一和分析您的测试结果，看看maven-dashboard甚至是声纳 。
在这里绘制树是没用的，因为它不会显示依赖树，以前用于绘制它的m2-eclipse插件但它们删除了function，有多糟糕。 但是，在设计CBD时忘记技术。 EAR没有模块，如果不是严格必要的话，它可能是一个技术障碍。 通常，EAR依赖于WAR，而WAR取决于依赖于其他JAR的JAR – 它们中的每一个都是一个组件。
基于您给出的第一个示例，共享库是一个垂直组件，它不依赖于您的任何模块，我不确定您所选择的技术/框架，但使用Spring，我们可以轻松地共享配置文件组件（垂直组件，如“基本测试”组件，例如，可以提供类以简化配置和测试实现）。 继续这个例子， 子模块2可能依赖于子模块1 ，在这种情况下， 子模块1将有自己的测试和模拟; submodule2将有自己的测试和模拟，当使用submodule1时 ，将提供模拟数据。
也许你已经知道，但我推荐两本书：（1）Eric Evans的经典“领域驱动设计：解决软件中心的复杂性”; （2）John Cheesman和John Daniels撰写的“UML组件：指定基于组件的软件的简单过程”（作者）。