Develop Reference

Executing a single test in an installed maven jar

I have a jar installed in my local ~/.m2 repo and I would like to execute a single test using the -Dtest option via a python script. I tried using this command on the command line mvn surefire:test -DdependenciesToScan=groupId:artifactId -Dtest=NameOfTest, however it doesn't seem like maven is finding the NameOfTest in the groupId:artifactId dependency and returning back with no tests executed? Any way to execute a single test in an already installed maven artifact?

Typically Java classes in src/test/java (or your corresponding test sources directory) will not end up in a built artifact by maven by default. If you inspect the contents of the JAR, you will likely notice no compiled test classes, which is why maven can't find them.
If you really want your test source compiled into the JAR, there are plugins to help you. Particularly, the standard Maven JAR Plugin.
However, I would suggest you consider carefully why you need test classes in a built artifact. The standard use of test suites is to test the main source code being built. There are some situations that have been argued where having tests in the final artifact are valid, but they are rare and usually can be worked around in other ways ( Related discussion ).

Tell Eclipse to skip tests

Is there a way to tell only Eclipse to skip various individual junit tests (but still run the rest of them)? I am familiar with the #Ignore annotation, but that is not what I am looking for because that will cause the tests to always be skipped.
I would like the tests to be skipped when ran by eclipse (Run As -> Junit Test) but ran in any other context, most likely during a maven build.
Any ideas?

So far the following solution has worked well. It is not a complete solution because it causes the tests to only be ran by maven when maven is invoked from the command line. For now though, it works.
When maven is invoked, the maven command line arguments are placed in the environment map (System.getenv()). When the tests are run through jUnit in eclipse, there is no entry in System.getenv() for the maven command line arguments. So, I am using jUnits Assume class to check that this property is not null for the tests that I want eclipse to skip.
Code:
Assume.assumeNotNull(System.getenv("MAVEN_CMD_LINE_ARGS"));
FYI, one downside of this solution is that eclipse marks the tests as passed instead of skipped.

why sonar:sonar needs mvn install before?

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.

Setting cucumber-jvm options in Maven from the command line

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).

Why is my Mockito-based unit test unable to run in Eclipse?

I have a Maven-managed project that uses Mockito mocking in its unit tests. I can run all the tests within a Maven build, and they run without error (and pass!). However, if I right-click a single test function, and choose "Run As -> JUnit Test", I get an exception java.lang.NoSuchMethodError: org.mockito.Mockito.doAnswer(Lorg/mockito/stubbing/Answer;)Lorg/mockito/stubbing/Stubber;. Of course, the "missing" method is there if I look at the sources, and like I said the tests compile and run from the command line.
Best I can think of is if Eclipse is trying to "help" me by providing an outdated Mockito artifact (I'm using 1.8.5 in my Maven dependencies) for the JUnit plugin, akin to how the Maven plugin can stick you with an oddball version of the Maven runtime for certain tasks.
Is this the problem? Is it something else? Can I fix this?
ETA: Apparently this may relate to a known issue. There's a good chance that it stems from having multiple versions of Mockito in my classpath (thanks, Maven :-/ ). I seem to have my house in order -- Eclipse can run the tests now -- but unfortunately the bug has bitten my Hudson. I have to track down how to remove the old JAR from the classpath there as well.

Make sure the unit-test classpath has the correct mockito. You can check this from the run dialog. Btw, Eclipse does not ship with mockito, so perhaps you are having two versions of it. Take a look at your maven dependency graph and search for duplicates.

I had the similar problem and I found that I had both "mockito-all 1.8.x" and "mockito-core 1.9.5" in my classpath. I was supposed to use only 1.9 but somehow eclipse was putting 1.8 before 1.9.5 in the classpath. I removed 1.8.x and it worked ;)