I try to make parallel execution using JUnit5 + Maven Surefire Plugin. For that I made some settings:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M4</version>
<configuration>
<properties>
<configurationParameters>
junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent
</configurationParameters>
</properties>
</configuration>
</plugin>
</plugins>
And it works correctly for test methods that marked annotation #Test.
But I also have tests that marked annotation #ParameterizedTest and I expect that they should run in parallel using different values from the source. But it doesn't work as I expect - it runs in one thread.
Is there possible to fix that or it is a feature in JUnit 5.
Use #Execution(ExecutionMode.CONCURRENT) tag along with #ParameterizedTest to run the scripts in parallel for the each set of data.
Related
I've a pretty standard Java-Maven build with some plain JUnit tests and some for Arquillian. JaCoCo is hooked via Maven like this:
<properties>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
</properties>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
<append>true</append>
</configuration>
<executions>
<execution>
<id>agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Running Sonar now seems to work, however the code coverage is all wrong. I'm not sure if these are separate issues or if there is one problem with the configuration producing all of them, so I'll just list them:
test suites are not run at all (meaning JUnit tests with #RunWith(AllTests.class))
Arquillian tests (with #RunWith(Arquillian.class)) are run, but the code coverage is wrong, i.e. entities have a code coverage of 0%
an entire module is not tested and I'm not sure why (all but one of the tests has #RunWith(Parameterized.class), but this annotation works in another module)
(After Qword's suggestion I tried it without the reportPath. However the reports in target/sites/jacoco/ are still missing the coverage.)
I'm wondering if the problem is with the JUnit runners or maybe because some of these tests are in another module than the classes they test (Arquillian / integration tests especially). On the other hand, some of the JUnit runners seem to work as well. Maybe it's a third component that breaks the build.
I tried arquillian-extension-jacoco as well, this plug-in doesn't seem to work at all (tests won't even start).
Is the problem with the JUnit runners? With the integration tests? How do I fix this?
You don't actually need to specify sonar.jacoco.reportPath. First of all, it's been deprecated in favor of sonar.jacoco.reportPaths. Second, if you specify the latter property, all reports will be created in a single binary file, but this is not default Jacoco behaviour (and SonarQube deprecated that as well).
I would suggest, as a first step, to
Entirely remove properties sonar.jacoco.reportPath and sonar.jacoco.reportPaths
Remove the configuration node from Jacoco plugin definition
Now, you'll won't find anymore the jacoco.exec file but instead for every module you'll find a new directory target/sites/jacoco in which there will be reports in CSV, XLM, and HTML. This is the standard Jacoco behaviour in v0.8.4.
I'm not entirely sure this will fix all your problems, but at least
I'm quite sure SonarQube will be able to correctly pick up the reports and show the coverage
You'll be able to analyse coverage with a simple mvn clean install on your local machine without having to go to SonarQube every time
Is it possible to change the order of test execution based on #Tag? I want to have all the tests marked with #Tag("fast") executed before #Tag("slow").
Im interested in solutions for IntelliJ IDEA and Maven. Both do not care about the order in which the tags are configured.
My config for Maven:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.0</version>
<dependencies>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
<version>1.2.0</version>
</dependency>
</dependencies>
<configuration>
<properties>
<includeTags>fast,slow</includeTags>
</properties>
</configuration>
</plugin>
I guess my best bet is to run the suites separately.
JUnit Jupiter only makes a single pass over the test classes and executes all tests whose tag is active, so it does not order. For a tool to order tests by tags, it would have to run JUnit several times, once for each tag, but no tool does that out of the box.
In IntelliJ you can run all tests with a specific tag (earch for "#Tag"), so you could generate several such configuration. In Maven you could give Surefire and Failsafe different tags to execute, although that would only buy you two executions instead of one.
I have implemented a Maven plugin which is used to create test database (with random name) before Maven test phase, and drops that database when the test phase is completed.
The plugin need to be executed two times, before test phase (when is used to create database) and after test phase (when is used to drop that test database).
Which Maven lifecycle phase will be always executed after test phase, whether test phase is successfully executed or not?
There are no particular phase in the Maven lifecycle that corresponds to pre- and post-test. This is because unit tests are not supposed to require an external environment. It sounds like what you want to do are not unit tests but integration tests instead, because they require an environment to be set up.
From the docs:
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
And there is a pre-integration-test, integration-test and post-integration-test that are used to setup, run and destroy the test environment.
pre-integration-test: perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test: process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test: perform actions required after integration tests have been executed. This may including cleaning up the environment.
As such, it would be easier and a lot cleaner to do this in integration-test phase using the maven-failsafe-plugin.
Now, if you really want to run that as unit tests, I would not write the creation / deletion of the database as a Maven plugin. It would be a lot better to let your application create the test database when it is configured in a test environment. (For example, if you're using Spring, it has a lot of facilities for that.)
And, if you really want to run that as unit tests in the test phase, and using your plugin, you will have to skip the default execution of the maven-surefire-plugin and then define an execution of your Maven plugin creating the database, a new execution of the maven-surefire-plugin and an execution of your Maven plugin dropping the database, bound to the test phase.
This works because Maven invokes the plugins in the order as they are defined in the POM when they're bound to the same phase.
A configuration would look like:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<id>default-test</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId><!-- group id of your plugin --></groupId>
<artifactId><!-- artifact id of your plugin --></artifactId>
<version><!-- version --></version>
<executions>
<execution>
<id>create-db</id>
<phase>test</phase>
<goals>
<goal><!-- your goal --></goal>
</goals>
<!-- add configuration -->
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<id>test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId><!-- group id of your plugin --></groupId>
<artifactId><!-- artifact id of your plugin --></artifactId>
<version><!-- version --></version>
<executions>
<execution>
<id>drop-db</id>
<phase>test</phase>
<goals>
<goal><!-- your goal --></goal>
</goals>
<!-- add configuration -->
</execution>
</executions>
</plugin>
maven-surefire-plugin enables running JUnit tests in parallel[1] - is there way to run JUnit-Tests in Eclipse in parallel, too?
[1] e.g.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<parallel>methods</parallel>
</configuration>
</plugin>
"Running tests in parallel" https://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html
You can use tempus-fugit to run tests in parallel in Eclipse. This should work.
We develop multiple branches of a project concurrently. Each developer has multiple working copies, each working copy uses its own DB schema. (There will typically be a working copy per branch, but sometimes even more than one working copy per branch.) We need to let Maven know the DB credentials (for the db-migration plugin, for unit tests, for the dev instance of the servlet).
We can't put the credentials in the pom.xml because each developer might use different DB schema names. We can't put the credentials in settings.xml because each developer uses more than one schema.
Where do we put the credentials?
For example, http://code.google.com/p/c5-db-migration/ describes that the DB credentials need to be present in pom.xml but I would like to externalize them out to a file that's not under revision control.
You could put them into a properties file inside the project directory but which is excluded from source control.
With Maven it's possible to read properties from an external file by using a <build><filters><filter> element as instructed here.
Read following answers:
How to read an external properties file in Maven
Reading properties file from Maven POM file
Read a file into a Maven property
or just:
<project>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
</execution>
<configuration>
<files>
<file>dev.properties</file> <======== IT IS!!!!!
</files>
</configuration>
</executions>
</plugin>
</plugins>
</build>
</project>