I have a maven super pom, consisting of multiple modules. I run mvn emma:emma on the super pom, and I get emma code coverage for all the modules (that have tests defined.)
Now I wish to exclude one of the modules from the emma code coverage run. Such that when I run mvn emma:emma on the super pom, the specific module does not get code coverage measured. But when I do mvn test all module tests will be executed as normally.
How do I do that?
As I see in Maven Emma plugin docs, there's not such property to exclude some projects (modules) from coverage measurement. It seems that all reactor projects will be handled by Emma plugin.
What can be useful in your case is the plugin's ability to exclude some test classes (maven.emma.filter.excludes property) from coverage report, but it would work only of you're able to specify masks that catch test classes of modules' you want to effectively exclude, so it might not work in your case.
Related
My project is composed of several DLLs that I must test with different unit tests. I generate an XML file for each of the tests then I transform them into a JUnit format to be read by Jenkins. It works very well.
On the other hand, the test results are all in the same topic on the Jenkins interface and I would like to separate them for each DLL. It is for a more practical aspect for the visualization of the tests. I haven't found the solution yet. That's why I'm asking you if there is a solution for this problem.
I tried several plugins like JUnit or Warning NG. But the result remains the same. The JUnit plugin puts all the results in the same section and makes no distinction and the Warning NG plugin fails to parse the XML report to display it in Jenkins.
I use Coverity to scan my project for security issues.
What I would like to know is how to exclude any java test (NOTE: both integration and unit) from the analysis results that are available after a defect commit.
I did use maven to build the project and I excluded Unit tests using the flag -Dmaven.skip.test=true.
Though that made Coverity not scanning unit tests, it still makes it scan integration ones.
All the integration tests in my project contain the word "Test" in the file titles. Therefore I started looking at the filter section made available in Coverity. What I tried then was a regex (.*(!?(Test).*)$) but it did not work. It seems that coverity supports two matching character (* and ? - see image below) while it does not seem to support any negative look-around.
Is there any good way to accomplish this task in an easy and clean fashion?
Since Coverity relies on your Maven build, you can exclude:
compilation and execution of both unit tests (by Surefire plugin) and integration tests (by Failsafe plugin) by adding -Dmaven.skip.test=true
execution of both unit and integration tests via -DskipTests
execution of integration tests via -DskipITs
Instead, if you have your integration tests in a separate Maven module, you can directly exclude that from the Maven build via profile, like in below example -- see extract of aggregator's pom.xml and maven command line to be launched:
<modules>
<!-- remove 'my-it-module' from this list -->
</modules>
<profiles>
<profile><id>build-it</id>
<activation><activeByDefault>true</activeByDefault></activation>
<modules><module>my-it-module</module></modules>
</profile>
</profiles>
and then mvn install -P !build-it
I have a set of test cases, for which I need to demonstrate an analysis. Is there a plugin or any other way to analyse test results?
You can use Cobertura Maven Plugin for analysing and code coverage reports on the unit tests.
You can refer the below links for more details on Cobertura Maven Plugin:
http://www.mojohaus.org/cobertura-maven-plugin/
https://www.mkyong.com/qa/maven-cobertura-code-coverage-example/
For Netbeans, you can refer tikione-jacocoverage plugin from below link:
http://plugins.netbeans.org/plugin/48570/tikione-jacocoverage
As an additional note, we manage our project builds with Maven.
Let's say we have three GWT modules, only one of which has an entry point. The other two modules are inherited by the module containing the entry point.
We practice MVP and strive to keep the majority of our testing as normal JUnit tests, but some integration tests require us to use GWTTest. We keep these to a minimum.
We would like to keep the actual tests with the modules containing the code they are testing. My thought was to ensure that maven only executes JUnit tests for the sub-module builds. The GWTTests in the submodules would be rolled up into a test suite. Then, the entry point project would contain a GWTTestSuite which rolls up the submodule test suites along with and other GWTTests that the entry point module may have.
At this point, my problem is that the entry point GWTTestSuite can't resolve the tests from the submodules ("no source code is available........did you forget to inherit a required module"). I've tried creating the test-jars for the submodules and adding them as dependencies to the test scope, but when GWT is executing the primary GWTTestSuite, it can't find the submodule test suites (or their underlying gwt tests). I can see the GWTTests in the .m2 repo test jars.
So, how do I get the GWT compiler to "see" the submodule tests?
Update:
I have not yet been able to figure out how to do this. The cleanest thing I can manage is to keep the normal JUnit tests co-located with the submodules, but keep all GWT Tests for all modules in the main module.
I have a maven build process that publishes executable jars and their tests to Nexus.
I have another maven build process that needs to access these jars (executable + test) and run the tests.
How do I go about it? So far I have managed to do this only if the jar is exploded to class files.
I am new to maven and completely lost in the documentation.
Update 2022-03-11
The feature has been implemented, see https://stackoverflow.com/a/17061755/1589700 for details
Original answer
Surefire and failsafe do not currently support running tests from within a jar.
This is largely a case of not being able to identify the tests.
There are two ways to get the tests to run.
Use a test suite that lists all the tests from the test-jar. Because the test suite will be in src/test/java (more correctly will be compiled into target/test-classes) that will be picked up and all the tests in the suite will be run by Surefire/failsafe (assuming the suite class name matches the includes rule: starts or ends with Test)
Use the maven dependency plugin's unpack-dependencies goal to unpack the test-jar into target/test-classes (this screams of hack, but works quite well)
The main issue with the first option is that you cannot easily run just one test from the suite, and you need to name every test from the test-jar
For that reason I tend to favour option 2... There is the added benefit that option 2 does not mean writing code to work around a limitation in a build tool plugin... The less you lock yourself into a specific build tool, the better IMHO
This actually works quite fine with the newer surefire and failsafe plugins, see related questions:
Run JUnit Tests contained in dependency jar using Maven Surefire
run maven tests from classpath
So you don't need to unpack the jar anymore, you just provide the group and artifact id for the dependencies to scan (this works with both "main jar" dependencies, as well as "test-jar" dependencies)
The attached test-jar can be used as a usual dependency in other project which supports reuse of code in the test area but you can't run tests out of the jar. If you really need the solution you have to write at least a single suite (etc.?) to start the tests from the jar.