Maven文件夹布局:我应该在EAR或其子模块中放置测试吗? [英] Maven folder layout: Should I place tests in the EAR or its sub-modules?

查看：114 发布时间：2020/5/10 20:55:19 java maven module integration-testing jboss-arquillian

本文介绍了Maven文件夹布局:我应该在EAR或其子模块中放置测试吗?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我们有一个EAR项目，其中包含几个子模块(多个EJB，Web项目，应用程序客户端等).单一测试的自然范围是它们各自的子模块(因为它们应该是测试孤立的单元).

在很短的时间内，我们引入了不明显的测试依赖关系.项目是来自其他项目等的模拟功能.不久，我们的体系结构就演变为带有模拟的几个独立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进行功能测试，但我希望不久后可以使用功能完备的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 Project中吗?我应该在EAR项目中放置集成/验收测试，还是在子模块中放置整体测试?还是应该将所有内容都放在子模块中?

更新:替代方法.我应该将集成测试隔离到一个单独的模块中吗?如果是这样，如何(我应该如何设置依赖项，配置Arquillian等)?

解决方案

让我介绍一些有关如何与Maven进行集成测试的实用信息，以便其他苦苦挣扎的人可以做正确的事情™. >

我最终遵循了很棒的建议(即使有些古老)使用Maven构建更好的版本以及 Codehaus Maven和集成测试指南.

使用聚合器顶级项目:

myproject
    myproject-ear
    myproject-war
    myproject-ejb
    ...
    myproject-integration-tests

正如mchamati建议的一样，让每个模块自己进行单元测试(就像以前一样).单元测试速度很快，并且可以在每个版本上运行.
对于单元测试，事实证明我的最初策略还不错.我仍然有几个模拟模块绑定到EAR作为托管依赖项.

有一个单独的集成测试模块，其包装类型可以是pom； (您不会从该项目中构建真正的可部署工件；此外，当测试数量开始增长时，将其转变为另一个聚合器pom可能是有道理的):

<project xmlns="http://maven.apache.org/POM/4.0.0" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
        http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <artifactId>myproject</artifactId>
        <groupId>com.mycompany</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.myproject</groupId>
    <artifactId>myproject-integration-tests</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

遵循Maven约定，集成测试应进入src/it:

<build>
    <testSourceDirectory>src/it</testSourceDirectory>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>testCompile</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

使用故障保护来运行集成测试:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.17</version>
    <configuration>
        <encoding>${project.build.sourceEncoding}</encoding>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.surefire</groupId>
            <artifactId>surefire-junit47</artifactId>
            <version>2.17</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

让您的集成测试项目导入ear项目依赖项(以及您需要的所有其他内容).我不确定这是否是一种好的做法，因为在任何指南中都没有提到它，但是它对我来说很好.
```
<dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>my-project-ear</artifactId>
    <version>1.0-SNAPSHOT</version>
    <type>pom</type>
</dependency>
```

在集成测试模块中集中 arquillian 相关配置:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>${arquillian.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.11</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.jboss.arquillian.junit</groupId>
        <artifactId>arquillian-junit-container</artifactId>
        <version>${arquillian.version}</version>
        <scope>test</scope>
    </dependency>
    <!-- Arquillian container related dependencies, etc -->

遵循失效安全命名约定用于测试文件.

src/it/java
    com/mycompany/myproject
        mypackage
            MyIT.java 
            MySecondIT.java
        anotherpackage
            YetAnotherIT.java

利润

在顶级聚合器项目下:
1. mvn test⇒运行充满模拟的快速单元测试
2. mvn verify⇒运行实际的集成/功能/验收测试(可能很慢)

其他提示:如果您正在运行CI服务器，例如 Jenkins 设置您的每晚构建以运行集成测试(即，进行构建调用mvn verify).不要将未经验证的内部版本部署到认证服务器或生产服务器.

We have an EAR project with several sub-modules (multiple EJBs, Web Projects, Application Clients, etc). The natural scope for unitary tests are their respective sub-modules (since they are supposed to be testing isolated units).

In a short amount of time we have introduced non obvious testing dependencies. Projects were mocking functionality from other projects, etc. Soon our architecture evolved to several stand-alone jar files with mocks (web project 1 mocks, ejb 2 mocks, etc); we wire those mocks against the EAR and consume the mocks in the sub-modules ("Skinny War" style).

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

Anyway, the consensus among our team is that mocks are getting out of control. We want to evolve towards Arquillian and testing inside the container (e.g., towards Integration tests). We are also introducing ATTD (initially just functional tests with Drone, but I wish to have a fully functional Thucydidies + JBehave or EasyB setup soon).

Tests may depend on resources from multiple sub-modules. ShrinkWrap is there to guarantee that things do not get out of hand.

So my question is: Where should I put tests, stories, Arquillian configuration files and so on?

I feel like the EAR is the best place to group everything:

EAR
   Modules
   Test
     src
        Java
           Test 1
           Test 2
        Resources
           Configuration Files  
           Stories
              Story 1
              Story 2

This would allow us to have a single unified report, forget about inter-modular dependencies, have a single point of configuration and so on.

But I might be wrong (working with per-module granularity have its advantages).

So what is considered best practice for Arquillian tests: Should I place my test files in the EAR Project? Should I place integration / acceptance tests in the EAR project and unitary tests in the sub-modules? Or should I put everything in the sub-modules?

Update: Alternative approach. Should I isolate integration tests into a separate module? If so, how (how should I set dependencies, configure Arquillian, etc)?

解决方案

Let me put a little bit of practical information about how to organize integration tests with Maven so that other people struggling with it may Do The Right Thing™ .

I ended up following advice from the fantastic (even if somewhat old) Better Builds with Maven as well as Codehaus Maven and Integration Testing Guide.

Use an aggregator top level project:

myproject
    myproject-ear
    myproject-war
    myproject-ejb
    ...
    myproject-integration-tests

As suggested by mchamati, have every module test itself with unit tests (just as before). Unit tests are fast and can be run on every build.
Also for unit tests, it turns out that my initial strategy was not so bad. I still have several mock modules bound to the EAR as managed dependencies.

Have a separate integration tests module, its packaging type can be pom; (you will not build an real deployable artifact out of this project; also, when the number of tests begin to grow, it may make sense to turn it into yet another another aggregator pom):

<project xmlns="http://maven.apache.org/POM/4.0.0" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
        http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <artifactId>myproject</artifactId>
        <groupId>com.mycompany</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.myproject</groupId>
    <artifactId>myproject-integration-tests</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

Following Maven conventions integration tests should go into src/it:

<build>
    <testSourceDirectory>src/it</testSourceDirectory>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>testCompile</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

Use failsafe to run integration tests:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.17</version>
    <configuration>
        <encoding>${project.build.sourceEncoding}</encoding>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.surefire</groupId>
            <artifactId>surefire-junit47</artifactId>
            <version>2.17</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Have your integration-tests project import the ear project dependencies (and everything else that you need). I'm not sure if this is considered good practice since it was not mentioned in any of the guides, but It worked very well for me.
```
<dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>my-project-ear</artifactId>
    <version>1.0-SNAPSHOT</version>
    <type>pom</type>
</dependency>
```

Centralize arquillian related configuration in the integration tests module:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>${arquillian.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.11</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.jboss.arquillian.junit</groupId>
        <artifactId>arquillian-junit-container</artifactId>
        <version>${arquillian.version}</version>
        <scope>test</scope>
    </dependency>
    <!-- Arquillian container related dependencies, etc -->

Follow failsafe naming conventions for test files.

src/it/java
    com/mycompany/myproject
        mypackage
            MyIT.java 
            MySecondIT.java
        anotherpackage
            YetAnotherIT.java

Profit

Under the top level aggregator project:
1. mvn test ⇒ Runs the fast unit tests full of mocks
2. mvn verify ⇒ Runs the real integration / functional / acceptance tests (may be slow)

Extra hint: If you are running an CI Server such as Jenkins setup your nightly builds to run the integration tests (i.e., have your build call mvn verify). Do not deploy unverified builds to homologation or production servers.

这篇关于Maven文件夹布局:我应该在EAR或其子模块中放置测试吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文

Maven文件夹布局:我应该在EAR或其子模块中放置测试吗? [英] Maven folder layout: Should I place tests in the EAR or its sub-modules?

问题描述

相关文章

Java开发最新文章

热门教程

热门工具

登录关闭

Maven文件夹布局:我应该在EAR或其子模块中放置测试吗? [英] Maven folder layout: Should I place tests in the EAR or its sub-modules?

问题描述

相关文章

Java开发最新文章

热门教程

热门工具

登录 关闭

登录关闭