Effective Mockito Part 1

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.

Screen Shot 2011 09 12 at 8.37.40 AM Effective Mockito Part 1As 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.

Screen Shot 2011 09 12 at 8.38.31 AM Effective Mockito Part 1But 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.

Screen Shot 2011 09 12 at 8.41.16 AM Effective Mockito Part 1As 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.

Screen Shot 2011 09 12 at 8.41.29 AM Effective Mockito Part 1As 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 icon wink Effective Mockito Part 1

followme Effective Mockito Part 1

Read the other Effective Mockito posts:

You may also like...

Share this Post

Twitter39
Google+19
LinkedIn
Facebook

Tags

7 Responses to “Effective Mockito Part 1”

  1. Andrew says:

    This very quickly drove me up the wall when I started using Hamcrest/Mockito/Powermock, so I was very glad when I found out about it – I’m sure this will prove useful to a lot of people.

    It’s also good for things like Apache Commons IO/Lang, both of which have a number of classes full of useful static methods.

  2. Ralf Sternberg says:

    Cool! That was a new one for me. Thanks for sharing!

  3. Also useful for asserts (JUnit or TestNG or FEST)

  4. Hi Andrew, thats true. It’s useful where ever static imports are useful ;)

  5. PhoenixD says:

    Hmmm this doesn’t appear to work for me (Indigo)… I can enter everything to a specific type but not a “*” like you have. Pretty sure they are static (I am using jMockit, Hamcrust)

  6. Hi PhoenixD,
    I guess you are on the wrong preference page. That happens to me also the first times. Please be sure you followed the preference hierarchy like in the screenshot. Hth.

  7. Col says:

    @PhoenixD: I was experiencing the same problem. Don’t add the ‘.*’ when you add a new type. Just enter ‘org.junit.Assert’ and the ‘.*’ will be automatically added.

    @Holger: Great information. Looking forward to reading more of the series.

7 responses so far

Written by . Published in Categories: Planet Eclipse