I have around 20 modules need to built and how I could achieve this in faster way using maven 2.0+
Currently my build starts from root pom.xml using hudson
just calls mvn clean install
I do not want to skip any of the unit tests as well.
Currently it is taking almost an hour.Please advice.
Thanks
Wish I had more "high tech" suggestion but I would start by splitting tests into two groups:
"Fast" ones which will be part of every build and
"Slow" ones which will be part of "Slow" build. The "Slow" build is run several times a day.
Usually, unit tests are fast and become part of the "Fast" build while integration tests are part of the "Slow" build.
I would be careful with parallel tests: they can create more problems than they solves.
You can read more on integration test implementation in Maven here: http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
What Sasha O said is really important. If your build takes so much times, maybe your tests are not simple unit tests. So splitting the tests among two categories will be a good idea. Your fast tests should be real unit tests, which means that they should not involve Spring context, important disk I/O, or real database connection (you can use in-memory database, such as H2 or HSQLDB).
If you are using TestNG for your tests, you can use the groups feature to split your tests. If you are using JUnit, the #Category can be useful. Using JUnit, this #Category is not perfect, and it was a problem for me. I solve my problem by creating a custom JUnit Runner (the solution is not perfect neither, but can be helpful).
Another advice: maybe you could consider using a better hardware for your continuous integration server. Indeed, compilation and tests execution can be really improved by using a computer with better performances. As well, if you are not using a recent JDK, you may migrate to JDK 1.6 for example...
Finally, there is an interesting option with Maven since version 2.1: the incremental build. This option is available when you click on the "Advanced" button of the Maven build options if you are using Hudson / Jenkins.
The principle is to build only the modules that are impacted by your changes (i.e. commits). Let's take an example. I have this project:
project
+- commons
+- persistence
+- business
The business project is dependent on persistence, which is dependent on commons. Now, if you have a commit on the persistence project, why would you need to compile, test and package commons, as this project did not change? The incremental build option will only rebuild the modified project, as well as the dependent modules. In my example, persistence will be rebuilt, as well as business.
Related
I am adding basic regression testing to a Maven project that has no automated testing. My initial idea was to create a number of test classes, called IT<whatever>.java, to run in the integration-test phase. However, during packageing we do obfuscation and optimization and I want to be sure that the tests run against the final JAR (or at least the final classes).
The thing is, I can't tell from reading the docs what the actual difference is between the two kinds of test. The docs mention that integration-test is run after package, which sounds promising, but the tests are excluded from the JAR so it's unlikely they're running against the final artifact. Are they run against the packaged classes? Or is the only distinction between the two test types that they are run in different phases of the build lifecycle?
I have a large build where tests sometimes prevent creation of artifacts because they stall or terminate the build due to make module timeout. I'd like my build server to:
build and publish artifacts
run unit / integration tests
At present unit and integration tests execute during each module's test and integration test phases in the typical maven way. This is great for developers but places risk of lack of build. The build server can easily setup a build/publish step by skipping the tests and I'd like to run a testing only test that skips process-resources through package phases just running the tests. However, I'm fairly certain that maven will traverse all the previous stages again.
I'd like to avoid lengthening an already quite long build by needlessly rebuilding and repackaging my artifacts.
Has anyone split a maven build like this so the desktop developers get the benefit of test integration and the build server / continuous integration system get's the benefit of pushing risky tests to the end of the process so we always produce artifacts?
Am I trying to break the build up in the wrong fashion and should consider changing a monolithic end-to-end build in a series of smaller component builds?
Thanks
Peter
Here's how you can do this:
You can run maven and skip all tests to install/deploy your artifacts
Then you can run it again but this time only run the tests
Like so:
mvn install -DskipTests
mvn surefire:test failsafe:integration-test
If you have to do this all on one command line line, I'm sure you can figure something out by having two profiles. One that skips tests and one that only runs tests.
You could put the tests into their own modules which depend on the modules they test then use profiles to include/exclude the test modules as desired.
We have Desktop app deployed in OSGI bundles and have integration tests to test bundles loaded in OSGI container.
I am seeking a tool that calculates code coverage for integration tests with OSGI bundles
Currently we are trying to do with Jacoco and Sonar that is good for integration tests code coverage, but we aren't sure whether they are good enough to handle OSGI integration test code coverage
also any other tools available to calculate OSGI integration test code coverage.
Most, if not all code coverage tools should work with OSGi. Their general strategy is to post process the bytecode to inject extra code that allows them to measure such coverage. The biggest issue that causes is that this code now usually has dependencies on extra code (the code coverage library). Such dependencies can either be made explicit (by adding Import-Package statements) just like with any other dependency.
The other option you have is to add the code coverage library to your bootclasspath so you don't need those extra imports (which breaks modularity, normally not something you want, but in this case irrelevant). Once you solve this problem, the rest is a matter of instrumenting the right bundles and aggregating the results of multiple different test runs.
We proceeded in second approach and it worked..Jacoco is able to provide Test Coverage of OSGI integration test and show in Sonar DashBoard.
I have a Maven project that is a set of a Selenium 2 tests that run using JUnit. In other words the only thing in the whole project is JUnit testcases and they all reside in the normal source directory i.e. src/main/java since they are the main source files in the project.
I want to be able to run these same tests using Maven, but since these tests are not actual unit tests or integration tests within the project (they are not testing themselves, they are testing a web app somewhere else), I don't want them to run during the normal build lifecycle. However I still would like to be able to define the test phases/goals within the POM file.
At this point I sort of understand the way the surefire plugin works, I just don't know how to de-couple the executions from the build. I would like all my new executions to be stand-alone so that I can simply run them by doing something like: mvn run-webtests and have the run-webtests phase be something completely different from the compile and package goals of my project.
So I guess I have two overall questions:
1.) Am I on the right track or is there some better way to think of this problem?
2.) What is it that I need to do next to make this work? Create a custom phase? Create a custom goal?
Sorry for asking such a seemingly basic question, but I wasn't able to find any examples of someone doing anything like this.
I think you're on the right track. It's just that Maven is unfortunately lacking in flexibility in some areas. Usually stuff can be made to fit in, but sometimes it can be a real pain. I think the simplest way to make this work is to use a different naming convention for your selenium tests and make sure those are excluded from your "normal" test runs. Then define a profile where you configure the surefire plugin to include your selenium tests and exclude the others. Then to run the selenium tests, you could just
mvn test -P selenium-tests
The only ways that you can set it up so that you could run mvn run-webtests, are
Define a custom lifecycle where "run-webtests" is a phase in the lifecycle, or
Write a plugin, though executing a plugin always has a ':' in it, so it would be more like mvn myplugin:run-webtests.
Those are both more work and harder to maintain than a simple profile in the pom.
OSGI Testing frameworks - some observations.
I am in the middle of writing a system that makes use of OSGI. However all of the popular testing frameworks (Spring-OSGI, PaxExam) require a lot of artefacts for even the simplest test.
Wishlist / Goals
Ideally i would like a single Test that uses TinyBundle to assemble bundles and gives them to the framework. The framework will then do the heavy lifting of starting the container, deploying, running each test, updating the ui to show results etc.
On the surface it would appear that PAX-EXAM would satisfy this but it has additional requirements, which I have not been able to solve, within Eclipse. My problems are:
Each bundle requires a separate project.
Each project gets a manifest.mf in the $project/meta-inf/.
Ideally i would like to bundle all my manifests and "internal" classes in separate sub packages of the test rather than having them scattered about in their respective projects.
I have found packaging everything into the one project just does not work when the tests
execute even if the bundles provisioned are identical in content. However if i split everything into separate projects stuff just works.
Maven
I wish to avoid maven as this implies that a more complex system that would end up requiring building, deploying into the repo which in the end even when automated just slows things down even more. This would conflict with my use of Infinitest which automagically detects changed classes and just executes the right tests.
Eclipse Project Plugin launch configurations.
This approach requires one to pick the bundles to deploy prior to executing the junit test. This of course only works if one has separate projects with a one to one mapping per bundle. Again this goes against my attempts to consolidate all test dependeny bundles under one project.
How, Can it be done ???
How can i achieve this ?
Is this practically possible ?
Whats the simplest alternative ?
One alternative, which also leverages Pax Exam, is what we did in an OSGi testing framework (that tests OSGi framework implementations). Rather than duplicating the whole explanation of how it works, you can find that here:
http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework
It does not use Maven, and writing new tests is explained here:
http://opensource.luminis.net/wiki/display/OSGITEST/Writing+a+framework+test
Maybe some of the solutions can inspire you. All in all, there are many test frameworks out there for OSGi (just like there are for non-OSGi) but so far there has one been any one that "makes the rest obsolete".