87

I'm trying to crash through the brick wall between me and Mockito. I've torn my hair out over trying to get correct import static statements for Mockito stuff. You'd think someone would just throw up a table saying that anyInt() comes from org.mockito.Matchers and when() comes from org.mockito.Mockito, etc., but that would be too helpful to newcomers, no?

This sort of thing, especially when mixed in with myriad more import statements ending in asterisks, isn't always very helpful:

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

Yes, I know about and have been trying to use the Eclipse Window -> Preferences-> Java -> Editor-> Content Assist -> Favorites mechanism. It helps, but it doesn't hit the nail on the head.

Any answers to this question would be appreciated.

Many thanks, Russ

javanna
  • 59,145
  • 14
  • 144
  • 125
Russ Bateman
  • 18,333
  • 14
  • 49
  • 65
  • Sorry to jerk the community around: My original post also asked another question, but I discovered that it was something wrong with my code, due to a missing parenthesis, so I removed that bit. – Russ Bateman Sep 06 '11 at 16:04
  • Are you looking for a cheatsheet? We can probably whip one up? What's deficient about the api? http://mockito.googlecode.com/svn/branches/1.6/javadoc/index.html?org/mockito/Matchers.html – Tony R Sep 06 '11 at 16:42
  • 2
    So, you have to understand that I religiously avoid the asterisk in import statements because seeing that sort of thing at the top of code just means it's hopeless to know where a symbol comes from and, therefore, no way of figuring out what JAR to include in my project. Searching Javadoc in the browser isn't too good for finding symbols. Yeah, a cheat sheet would be really nice, but as a colleague and I were discussing just now, this is one of those problems you'd think the Java community would have solved by now. Thanks--let me know if you do one. – Russ Bateman Sep 06 '11 at 17:41
  • import static org.mockito.Mockito.*; helped me successfully compiled my code. – ZhaoGang Oct 31 '16 at 01:43

5 Answers5

112

Here's what I've been doing to cope with the situation.

I use global imports on a new test class.

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
import static org.mockito.Matchers.*;

When you are finished writing your test and need to commit, you just CTRL+SHIFT+O to organize the packages. For example, you may just be left with:

import static org.mockito.Mockito.doThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.Matchers.anyString;

This allows you to code away without getting 'stuck' trying to find the correct package to import.

Tony R
  • 7,136
  • 4
  • 21
  • 12
  • 1
    For Mac users, instead of CTRL+SHIFT+O do [command + shift + O](https://blog.codecentric.de/en/2012/08/my-top-10-shortcuts-for-eclipse-on-mac-os-x-and-windows-and-how-you-survive-the-change-from-windows-to-mac/#comment-165299) – Michael Osofsky Dec 02 '14 at 00:09
  • What is the downside to permanently using things like `import static org.junit.Assert.*;` in your test classes (not replacing them with `ctrl`+`shift`+`O` at the end)? – mkasberg Jan 22 '18 at 17:49
  • 3
    As I am always coming back to your reply for these 3 lines. Maybe you could update `import static org.mockito.Matchers.*;` to `import static org.mockito.ArgumentMatchers.*;` because `Matchers` is marked as deprecated – timguy Mar 06 '20 at 09:22
  • 1
    @timguy Thanks - I'll take a look! Hard to believe it's been 9 years... – Tony R Mar 06 '20 at 16:46
17

The problem is that static imports from Hamcrest and Mockito have similar names, but return Matchers and real values, respectively.

One work-around is to simply copy the Hamcrest and/or Mockito classes and delete/rename the static functions so they are easier to remember and less show up in the auto complete. That's what I did.

Also, when using mocks, I try to avoid assertThat in favor other other assertions and verify, e.g.

assertEquals(1, 1);
verify(someMock).someMethod(eq(1));

instead of

assertThat(1, equalTo(1));
verify(someMock).someMethod(eq(1));

If you remove the classes from your Favorites in Eclipse, and type out the long name e.g. org.hamcrest.Matchers.equalTo and do CTRL+SHIFT+M to 'Add Import' then autocomplete will only show you Hamcrest matchers, not any Mockito matchers. And you can do this the other way so long as you don't mix matchers.

Garrett Hall
  • 29,524
  • 10
  • 61
  • 76
  • 1
    Yup, you've nailed one of my complaints as a newbee: I'm not certain where an interface is from (JUnit, mock framework, Hamcrest, etc.) I spend more time trying to piece together a project from JARs than I really should have to (than I ever did back in day locating C interfaces from libraries and header files). – Russ Bateman Sep 06 '11 at 17:49
  • You might wax more eloquent on why you avoid assertThat: I haven't thought hard enough on it yet, but I'm just now trying to break into writing tests with mocks and the verify thing is new to me. Thanks. – Russ Bateman Sep 06 '11 at 17:51
  • Okay, I have another solution for you. Hope that helps! – Garrett Hall Sep 06 '11 at 18:08
5

For is()

import static org.hamcrest.CoreMatchers.*;

For assertThat()

import static org.junit.Assert.*;

For when() and verify()

import static org.mockito.Mockito.*;
ethemsulan
  • 2,241
  • 27
  • 19
1

My imports

import static org.junit.Assert.assertEquals;
import static org.mockito.ArgumentMatchers.anyInt;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import org.junit.Test;

And it works

SOUE77
  • 39
  • 6
0

import static org.mockito.Matchers.anyInt;

e.g. when(listMock.get(anyInt())).thenReturn("stackoverflow");

Jayant
  • 101
  • 1
  • 5