Using JUnit assertThat with Hamcrest matchers vs. fest-assert

881 views
Skip to first unread message

KARR, DAVID

unread,
Jun 3, 2014, 11:39:16 AM6/3/14
to moc...@googlegroups.com
What do most people do about assertions, as opposed to the Mockito "verify"? I'm not talking about the ordinary "assertEquals()" method, but the two (more?) variations of "assertThat()".

I initially started using fest-assert, because I felt that the assertions it produces are more "fluent", reading as chained method calls from left to right. It's slightly bothersome that it's easy to make the mistake of calling "assertThat(obj);" and not realize that this does nothing (you have to chain a predicate). I wrote a Sonar rule that checks for this anti-pattern to mitigate this. I also am concerned that "fest" might be a dead or dying project. It's hard to keep a relatively small extension like this alive as a project.

Because of those concerns, I wonder if using the "standard" JUnit "assertThat()" method with Hamcrest is a better option. You don't chain predicates the same way fest does, but that has tradeoffs either way. I believe that Mockito uses a version of Hamcrest internally, but only for mock objects, and it wraps the Hamcrest matchers with its own interface (is that all true?). Is there any problem with using a separate Hamcrest jar along with Mockito? I also see that Hamcrest Java hasn't had a release for almost 2 years now, although even the last release of Mockito is a bit older than that.

Stephen Duncan Jr

unread,
Jun 3, 2014, 11:44:49 AM6/3/14
to moc...@googlegroups.com
I use assertj: http://joel-costigliola.github.io/assertj/

It's an offshoot of fest-assert that is alive and doing well, just had
a release. I find it easier to use than Hamcrest (and I've used
Hamcrest plenty, so I think that's a fair judgement). For the few
places where I need to do custom assertions with Mockito (a
code-smell, in my opinion, something I try to avoid), I've been able
to get by with argument captors and making assertions using assertj.
Some assertj+mockito integration might be interesting, but it hasn't
come up enough for me to think of any concrete suggestions.
Stephen Duncan Jr
www.stephenduncanjr.com
> --
> You received this message because you are subscribed to the Google Groups "mockito" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mockito+u...@googlegroups.com.
> To post to this group, send email to moc...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mockito.
> For more options, visit https://groups.google.com/d/optout.

Eric Lefevre-Ardant

unread,
Jun 3, 2014, 1:06:13 PM6/3/14
to moc...@googlegroups.com

+1 for AssertJ
I'll add that the issue with assertThat() nor being followed by an actual assertion has not been a problem in practice for us.

Malte Finsterwalder

unread,
Jun 4, 2014, 4:28:32 AM6/4/14
to mockito
I have no experience with fest-assert or assertj. I've been using Hamcrest for a long time and never had any real problems.
I'm using the plain JUnit assertThat.

The biggest drawback with the fest-assert style IMHO is, that it's very hard (impossible?) to add your own assertions.
I have written a handfull of Hamcrest matchers over the years, which was helpfull, but would probably not be a killer in the end.

Greetings,
   Malte

Marcin Grzejszczak

unread,
Jun 4, 2014, 4:31:28 AM6/4/14
to moc...@googlegroups.com
Hi Malte,

when using AssertJ it's very easy to add your own assertions - check http://joel-costigliola.github.io/assertj/assertj-core-custom-assertions.html

AssertJ and fest allows you to profit from IDE's support and gives you assertions applicable for the given type. That is not the case when using Hamcrest.

Pozdrawiam / Best regards,
Marcin Grzejszczak
Senior software developer

Malte Finsterwalder

unread,
Jun 4, 2014, 4:50:43 AM6/4/14
to mockito
Hi Marcin,

thanks for the response. Looks interesting.
I still think the combinational nature of Hamcrest makes creating your own matchers a little easier, but over all that's probably negligible.
I will look into assertJ some more. The code completion aspect is interesting.

Greetings,
   Malte

Szczepan Faber

unread,
Jun 4, 2014, 5:33:17 AM6/4/14
to moc...@googlegroups.com
We tend to use groovy+spock to test the java code :D

For pure java projects, mockito + AssertJ/FEST is the way to go.

Cheers!
> --
> You received this message because you are subscribed to the Google Groups
> "mockito" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mockito+u...@googlegroups.com.
> To post to this group, send email to moc...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mockito.
> For more options, visit https://groups.google.com/d/optout.



--
Szczepan Faber
Principal engineer@gradle; Founder@mockito
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
http://www.gradlesummit.com

Marcin Zajączkowski

unread,
Jun 4, 2014, 3:32:01 PM6/4/14
to moc...@googlegroups.com
On 2014-06-04 10:31, Marcin Grzejszczak wrote:
> Hi Malte,
>
> when using AssertJ it's very easy to add your own assertions - check
> http://joel-costigliola.github.io/assertj/assertj-core-custom-assertions.html

In addition you could read an article by Tomek Kaczowski just about
custom assertions with AssertJ:
http://www.infoq.com/articles/custom-assertions

Marcin
--
http://blog.solidsoft.info/ - Working code is not enough

Reply all
Reply to author
Forward
0 new messages