Basically the header says it all, imagine I ran a testsuite, now some of the test have failed and I want to rerun those tests. I know that there is testng-failed.xml file generated by surefire plugin but I don't know how to pass that file as a parameter to TestNG through Maven. This is what I tried but unfortunately none of these commands have worked (they run all the tests again).
mvn verify -DsuiteXmlFile=testng-failed.xml
mvn verify -DsuiteXmlFile=target/surefire-reports/testng-failed.xml
Assuming you are at the root of the project and it has a standard layout, you can run:
mvn -Dsurefire.suiteXmlFiles=target/surefire-reports/testng-failed.xml test
You should try the correct parameter which is based on the documentation
mvn -Dsurefire.suiteXmlFiles=testng-failed.xml
A little bit late but for all who also stumble upon this question, khmarbaise answer works if you add the appropriate maven lifecycle.
mvn -Dsurefire.suiteXmlFiles=<path to testng-failed.xml> test
Related
I am trying to write unit test cases for an eclipse plugin. Went through http://www.vogella.com/tutorials/EclipseTycho/article.html#run-the-build-with-the-tests and created a eclipse-test-plugin.
So, the test plugin (let's call is plugin-b) has a dependency on another plugin for which the test is written (plugin-a).
When I run mvn clean install, I can see that tycho-surefire is trying to run the tests and in the process is trying to launch plugin-a. However, plugin-a requires a set of VM args to start correctly. Am trying to pass the arguments like below:
mvn -Dabc.properties=bridge\bundles\com.blah.blah.blah.blah.bridge\abc.properties clean install
but they aren't going through to plugin-a.
Any help is greatly appreciated.
Finally figured this out:
mvn clean install -Dtycho.testArgLine="-Dabc.properties=../../bundles/com.blah.blah.blah.blah.bridge/abc.properties"
That'll pass the system properties to the test runtime.
I have a large project that I am working on. I recently checked out our evolution branch, did a git pull and tried to deploy the app locally. It doesn't seem to recognize some libraries or jars in one Java class, so subsequently errors halt me from running. Basically, the import statements go unrecognized in the class.
Turns out I forgot to rebuild maven. When I ran mvn clean install from the command prompt, the build fails (even when I do mvn clean install -fn) as there are tests that fail. I don't often work with maven, or the command line, but here is my full stack trace when I run mvn clean install -e:
I'm running my project in the IntelliJ environment.
When I ran mvn clean install -fn, 'talent-app' was successful, but talent-core still failed and I still got
[INFO] BUILD FAILURE
Please let me know if you have any input, I appreciate it!
I'm not sure I understand your question correctly.
Basically, regarding your first paragraph, you said you had library issues but that after a clean rebuild - of your project, I suppose not of Maven itself - everything is fine?
Regarding the rest of your post, your build is failing because of a failing test case. This is shown by the line:
talent-core ............................... FAILURE
and by the output:
Failed to execute goal [...]. There are test failures.
If you go into the target/surefire-reports folder, you will find some files containing the output and error traces of each test, including the one that failed.
By scrolling up in your terminal, you should also be able to see which test was failing for talent-core.
From then on, by order of preference:
either look at the test reports as mentioned in the output, and attempt to figure our why the test is failing, and either fix the test or the code;
or skip the tests, you can add -DskipTests to the command-line. But you shouldn't skip your tests, really.
I currently try to run an integration test with maven failsafe, like described in here: reference link .
For this, I got 3 Modules: datamodule, datamodule2 and testmodule (all covered by a parent pom). testmodule depends on the two other modules. It got an test in src/test/java/ named MyTestIT.java. If I try to run the test with mvn clean test failsafe:integration-test, everything runs fine, but if I only run mvn failsafe:integration-test, it does not work. Does somebody know how it's this way?
If I try to run the test with surefire, for example with mvn test -Dtest=MyTestIT, it says it can't find MyTestIT in datamodule, and I need to set -DfailIfNoTests=false. If I try to run it with mvn test --pl testmodule, it says it can't find the dependencies (this only happens when they are not installed, but I don't want to call install everytime I run a test).
Is there any way of setting this in a pom, either in the parent pom or in the project pom? Or any other way of saying to maven "only run the integration tests, use the right dependencies and do not install everything"?
official documentation http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven says that the proper way of invoking sonar is:
mvn clean install -DskipTests=true
mvn sonar:sonar
but doesn't say why. how does sonar work? does it need compiled classes? so why not just mvn clean compile? or does it need a jar file? so why not just mvn clean package? what exactly does sonar plugin?
Explanation from a SonarSource team member:
In a multi-module build an aggregator plugin can't resolve dependencies from target folder. So you have two options:
mvn clean install && mvn sonar:sonar as two separate processes
mvn clean package sonar:sonar as a single reactor
I was surprised too, so I made a tweet an received the following answer from the official Maven account:
If the plugin is not designed to use the target/classes folder as a substitute, then yes you would need to have installed to get the jar when running *in a different session*. Complain to the plugin author if they force you to use install without foo reason [ed - #connolly_s]
The SonarQube analyzer indeed needs compiled classes (e.g for Findbugs rules, coverage). And since by default it executes tests itself, the compile phase can skip tests.
You can run SonarQube as part of a single Maven command if you meet some requirements:
As Mithfindel mentions, some SonarQube plugins need to analyze .class files. And if you run unit tests outside of SonarQube, then of course the testing plugins must read output from the test phase.
Got integration tests? Then you need to run after the integration-test phase.
If you want to run SonarQube as a true quality gate then you absolutely must run it before the deploy phase.
One solution is to just attach SonarQube to run after the package phase. Then you can get a full build with a simple clean install or clean deploy. Most people do not do this because SonarQube is time-consuming, but the incremental mode added in 4.0 and greatly improved in the upcoming 4.2 solves this.
As far as the official documentation goes, it's a lot easier to say "build and then run sonar:sonar" then it is to say, "open your POM, add a build element for the sonar-maven-plugin, attach it to verify, etc".
One caveat. SonarQube requires Java 6, so if you're building against JDK 1.5 (still common in large organizations), the analysis will have to happen in a separate Maven invocation with a newer JDK selected. We solved this issue with custom Maven build wrapper.
I am trying to set the "name" option for Cucumber to be able to run a specific feature or scenario.
I have entered this,
mvn test -DCucumber.Options--name="MyFeatureName"
but it just runs all the features and doesn't give an error.
Any ideas?
Here is a snippet from the Cucumber-JVM repo on how to run the java-helloworld example by passing cucumber options:
mvn test -Dcucumber.options="--format json-pretty --glue classpath:cucumber/examples/java/helloworld src/test/resources"
Keep in mind that it will override all the options in the #Cucumber.Options annotation you have on "RunCukesTest". I haven't got it to work for my own tests but maybe this will help.
So it looks like you need to give all the options needed to run cucumber, including the java class path and where the code is located using the "--glue" parameter.
Your tests are running in separate JVM, so you need to specify that system property in the test plugin configuration (i.e. surefire or failsafe plugin config in your pom.xml).