In our project, we run both junits and cobertura using maven. The problem I am facing is that,
junit test cases are running twice, once before the jar creation process and then once again for generating cobertura coverage reports. When running cobertura and junits with ant, we run junits only once since, cobertura runs along with junits. Is there a way to configure the above case with maven. I know we can use "maven.test.skip" property to skip junits. But when I do this, I am not able to see junit xml & html file reports.
Also, in maven how to configure junits to run in batch or parallel ?
thank you!
While I cannot find the exact page anymore, I recently read a discussion of why running the tests twice is considered a good idea. The key issues cited were around the effects of the Cobertura byte code alteration on the accuracy of your tests. In certain cases the timing of your code execution might be important, the byte code alteration can cause tests that fail in JUnit to pass when run only in Cobertura and vice versa. For this reason, it was recommended that the tests be allowed to execute twice. Most of the examples cited were around multi-threaded behaviors, but I imagine that there could be other cases were the byte code alteration can cause issues in your tests. Having the tests execute both ways provides you with baseline results and also reduces the chances of sending you on a wild goose chase if Cobertura is in fact altering test success.
Try adding cobertura as a compile scope reference. And post the relevant parts of your pom.
This happens because the reporting execution requires the test execution so it can create the reports. If there were a "site-only" goal on the site plugin that didn't have the #requiresDependencyResolution test annotation, it could be bound to the project's prepare-package phase and your reports would be generated without the tests running twice.
Unfortunately there seems to currently be no such goal (see my question on the subject).
See my answer to the question for details of a workaround.
Related
I'm new to SBT and I would like to know if it is possible to run tests without compiling. I mean to use a set of classes that have been already compiled.
Is this possible and what should I do to get this done?
sbt detects the available tests during compilation for efficiency. To run already compiled tests that are on the classpath and not in source files, it would be necessary to explicitly list them in the definedTests task. This isn't too straightforward, though.
I have Selenese with maven and testSuite with a lot of tests, my question how to run some of test cases?
Just like running any specific test in maven:
mvn test -Dtest=(YOUR_TEST_CLASS_NAME)
You can also supply test=TEST_CLASS* for all of that type, etc. Maven has some pretty good name and package matching. You may even be able to run a single test method by supplying the method name (although I have not tried this).
Check the Selunit maven plugin out, it provides include and exclude filters for Selenese suites in the pom.xml configuration.
I'm developing a Solr plugin and using the Solr test-framework I place a test SOLR_HOME dir under test/resources with /conf/ and /lib . Now the framework inistantiates a SolrCore and loads my plugin from /lib. Not an issue to output the jar of the plugin to /lib, but the issue is that the plugin is not yet available since it still needs to past the test (chicken and the egg).
How do you recommend solving this? I see those options:
Create another project for the tests with a dependency on the plugin, and in it run the tests. Simple enough, but how do I ensure that everytime the plugin is built also the tests of this other project is built? The point of the automated tests at every build is to having a new plugin jar which breaks the tests.
In dp4j pom.xml I build the project on 2 phases, in the 1st I <include> only the annotation processors while in the other I compile the tests which rely on the annotation processors compiled in the eariler phase.
I'm in favor of 2 since copy-pasting the configuration doesn't seem a bad option, and makes it seem less complicated than it probably is. I don't remember if I had asked about it here - what do you recommend? Any other case studies /working code to look at?
there's a 3rd. most probably best solution ~ do nothing!
I was under the impression that the Solr Testframework need to load my plugin from /lib but apparently it doesn't need to, it can load it from test-classes, all on its own!
I have an automated build script which involves unit testing of some GWT Modules in production mode. It appears that when these tests are run, they recompile the GWT module.
However, earlier in the build script, I have already compiled the modules. This is an obvious waste of effort. Does anybody know of any way to test a GWTTestCase to run in production mode, on modules that were already compiled.
I don't mind losing stacktraces or any information, because the build server only informs developers of which tests fails, and expects them to debug in their own environment.
This will be helpful for you
The main class in the test infrastructure is JUnitShell. To control aspects of how your tests execute, you must pass arguments to this class. Arguments cannot be passed directly through the command-line because normal command-line arguments go directly to the JUnit runner. Instead, define the system property gwt.args to pass arguments to JUnitShell.
For example, to run tests in production mode (that is, run the tests afer they have been compiled into JavaScript), declare -Dgwt.args="-prod" as a JVM argument when invoking JUnit. To get a full list of supported options, declare -Dgwt.args="-help" (instead of running the test, help is printed to the console).
Running your test in Production Mode
When using the webAppCreator tool, you get the ability to launch your tests in either development mode or production mode. Make sure you test in both modes - although rare, there are some differences between Java and JavaScript that could cause your code to produce different results when deployed.
If you instead decide to run the JUnit TestRunner from command line, you must add some additional arguments to get your unit tests running in production mode. By default, tests run in development mode are run as normal Java bytecode in a JVM. To override this default behavior, you need to pass arguments to JUnitShell
-Dgwt.args="-prod"
Well, I found a solution, but it is not elagant. I modified JUnitShell.maybeCompileForWebMode method, you should add VM argument -Dcompile=false to prevent compilation while running unit tests . You can get modified version of JUnitShell from here .
Parsing POMs
Discovered a new module be.howest:someproject someproject
It seems to find a new module on the first time I make a hudson job. Well, nothing really to worry, but it seems to execute everything twice, and I don't really know why. Another thing is: it gives this odd error (at least to me):
[WARNING] Removing: cobertura from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: findbugs from forked lifecycle, to prevent recursive invocation.
To me this looks like it tried to execute twice, but why is escaping me.
Also, it has a module under the build, which is something i'm not very familiar with, but I wouldn't bother too much (and consider it normal) if it didn't do my tests twice.
right now it is running two phases: clean and test. I changed it to clean package, because I included javadoc in the package lifecycle, but nothing has changed.
Hudson console log: http://pastebin.com/2GRmc2yP
Pom.xml: http://pastebin.com/HL9Qd821
Maven will execute tests first without any instrumentation, then it will execute cobertura plugin that will instrument the classes and re-run all the tests. Thus, the tests will be executed twice.
It is cobertura which makes the tests run the second time.