Last week I talked to a fellow developer, Frank Appel, about Mockito. We’ve been using this mocking library for over a year. We both agreed that of all the innovations we’ve tried in the last year or so, Mockito has boosted our coding productivity the most. With this blog series we want to share our experiences with Mockito. You see that I used the word “effective” in the title, and, in this context I want to define “effective” as arriving at clean test and production code as fast as possible.
To understand these posts you need to have a basic understanding of what mocking is. I recommend reading Martin Fowlers article,”Mocks aren’t Stubs“. You’ll also need some practice with Mockito. But, since you found this blog, you probably searched for the term Mockito 
, so this should be a given. Anyway, there is a third thing, that only affects this first post. You need to use Eclipse as your IDE. This post shows you how to setup Mockito in your IDE for the daily work. If you are using another IDE and you know how to achieve what I have described here, please share your tips in a comment. The follow up posts will not require Eclipse because they will be more Mockito specific. Enough prerequisites, let’s start with with the first thing that will boost your Mockito experience.
I always write tests first. My goal is to come up with a first test method really quickly to be able to create all the classes that I need by resolving the compiler errors using Eclipse’s quick fix functionality (CTRL/CMD+1 is your friend). What would be ideal, is to create a test class and just write the test without importing all the other stuff. The Mockito and Junit stuff should automatically appear in my content assist. When using Mockito, I want to create a test method, write “mo”, open the content assist and it should show me all the “mock” methods.
I’ll give you an example to make this clearer and to show how to achieve this. If I write a test method and open the content assist (which I use all the time), the standard selection options are very basic.
As you can see there are no “mock” methods but at least the Mockito classes. The reason is that the content assist only shows methods that are imported in the current class. So, by static importing Mockito this can be fixed.
But this is not what I want. This assumes that I have to import all Mockito stuff manually, or that I need to write “Mockito” and organize my imports automatically. I really want to be able to just write “mo” and get a pre-filled content assist. Luckily there is an option that lets us achieve this. In Eclpse it’s called “content assist favorites”. It can be configured within your preferences. Let’s take a look at our favorites.
As you can see, I added Mockito.*, Matchers.* and Assert.* to my favorites. This enables my content assist to show the available methods and import them when I’m using one. You may think, “hey, this will fill my content assist with unnecessary stuff when I’m writing production code.” But this is not the case. These imports are only available when Mockito and JUnit is on your build class path. So, by separating test and production code you only have these imports available in your test projects. Let’s take a look at the result.
As you can see I haven’t imported any Mockito stuff yet but I can select all the mock methods from my content assist. This enables me to write tests really quickly because I don’t have to think about setting up a test, I can just write it.
This is just a simple trick to come up to speed as quickly as possible when writing tests using Mockito. In the next posts I will focus more on the Mockito specifics. I hope you liked it and will stay tuned
Read the other Effective Mockito posts:
Tags: Java, Mocking, Mockito, Open Source, TDD, tips
.
