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
.