Beyond the Mockito Refcard – part 3 – mockito-core vs. mockito-all in Maven/Gradle-based projects

Posted: 2012-09-11 in Tricks & Tips
Tags: , , ,

Mockito team provides two jars: mockito-core.jar and mockito-all.jar. Which is better to choose for Maven or Gradle-based project? Both of them can be downloaded manually from a project webpage and also are available in Maven Central Repository. In many Maven projects I have found that mockito-all.jar was used which isn’t the best option and I will shortly explain why.

mockito-all.jar besides Mockito itself contains also (as of 1.9.5) two dependencies: Hamcrest and Objenesis (let’s omit repackaged ASM and CGLIB for a moment). The reason was to have everything what is needed inside an one JAR to just put it on a classpath. It can look strange, but please remember than Mockito development started in times when pure Ant (without dependency management) was the most popular build system for Java projects and the all external JARs required by a project (i.e. our project’s dependencies and their dependencies) had to be downloaded manually and specified in a build script.

On the other hand mockito-core.jar is just Mockito classes (also with repackaged ASM and CGLIB). When using it with Maven or Gradle required dependencies (Hamcrest and Objenesis) are managed by those tools (downloaded automatically and put on a test classpath). It allows to override used versions (for example if our projects uses never, but backward compatible version), but what is more important those dependencies are not hidden inside mockito-all.jar what allows to detected possible version incompatibility with dependency analyze tools. This is much better solution when dependency managed tool is used in a project.

I asked to forget about ASM and CGLIB for a while. It is time to explain why. As classes from those projects are repackaged inside a Mockito JAR (i.e. put into different packages than the original ones) and they are treated by a class loader just as different classes. This means that from a dependency management point of view they are just another Mockito internal classes. The Mockito developers explain it as a way to avoid some not fixed problems with CGLIB and a class loader met in the early development phase.

This post is the third part of the series Beyond the Mockito refcard extending recently released my Mockito reference card.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s