static import conflicts between Mockito and Hamcrest
KARR, DAVID (ATTSI)
I read an article about advanced Hamcrest matchers (http://www.dzone.com/links/r/hamcrest_your_unit_testing_friend.html) and I decided to try experimenting with some of those. The most obvious enhancement is the occasional "assertTrue(something > somethingother)", changing it to "assertThat(something, greaterThan(somethingother)".
I like using static imports for Assert-related classes, so I changed this block:
import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
to:
import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
import static org.hamcrest.Matchers.*;
This got the "greaterThan()" reference to compile, but I then had new compile errors elsewhere in the file, like references to "any()" being ambiguous.
What are my options for getting this arrangement to work?
KARR, DAVID (ATTSI)
Actually, it appears the conflict wasn't with Mockito, but internal to Hamcrest. I'm using v1.3.0RC2, and there appear to be multiple overloaded "any()" methods, and when I specify just a class argument, that's apparently ambiguous.
>
> What are my options for getting this arrangement to work?
>
> --
> You received this message because you are subscribed to the Google
> Groups "mockito" group.
> To post to this group, send email to moc...@googlegroups.com.
> To unsubscribe from this group, send email to
> mockito+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mockito?hl=en.
Holger Hoffstätte
>> This got the "greaterThan()" reference to compile, but I then had
>> new compile errors elsewhere in the file, like references to
>> "any()" being ambiguous.
>
> Actually, it appears the conflict wasn't with Mockito, but internal
> to Hamcrest. I'm using v1.3.0RC2, and there appear to be multiple
> overloaded "any()" methods, and when I specify just a class argument,
> that's apparently ambiguous.
I recently found the same problem. In many tests I could get around this
by simply not using unqualified static imports any more (you can easily
configure this as default behaviour in eclipse), but the conflict
between Mockito's any(Foo.class) and Hamcrest's
IsInstanceOf.any(Foo.class) still exists. You either need to fully
qualify the matcher or not use them together. :(
Not sure if there is a good solution to this except for one library to
change method signatures.
-h
Szczepan Faber
Hey,
If the conflict is about mockito's hamcrest vs your hamcrest then you can use mockito-core with your hamcrest i think. Just make sure there is only onPdee hamcrest on classpath.
For assertions I prefer fest-assert which imho is heaps better than assertions with hamcrest ;)
Cheers,
Szczepan
KARR, DAVID (ATTSI)
So, before I set this up, you’re suggesting replacing the “mockito-all” jar with “mockito-core” and “fest-assert”? What about the “objenisis” module? Should I still include that?
Holger Hoffstätte
> If the conflict is about mockito's hamcrest vs your hamcrest then you can
> use mockito-core with your hamcrest i think. Just make sure there is only
> onPdee hamcrest on classpath.
That's what I did, but the conflict with the unqualified static
any(..) import remains.
> For assertions I prefer fest-assert which imho is heaps better than
> assertions with hamcrest ;)
I did'n know about fest-assert and just read up on it. That looks
indeed much better and nicely solves the problem of static import
pollution. Looks like fest-assert is to Hamcrest what Mockito is to
EasyMock: simply better. Thanks for the pointer!
In case anyone else never heard of fest-assert and is looking for a
more elegant alternative/addition to Hamcrest:
http://code.google.com/p/fest/
-h