ArgumentMatcher.matches() and the use of assertions

[Chris Bartling]

The javadoc description for ArgumentMatcher.matches(java.lang.Object
argument) makes a statement about never using assertions within this
method and favoring returning false instead.

http://mockito.googlecode.com/svn/branches/1.6/javadoc/org/mockito/ArgumentMatcher.html#matches(java.lang.Object)

The documentation does not state why you should not use assertions
within your ArgumentMatcher.matches implementation. We recently used
assertions in this method and it worked really well, giving us a nice
stack trace to exactly the place in the custom ArgumentMatcher
implementation where the assertion failed. Is there something that
I'm missing here. The statement in the ArgumentMatcher seems awfully
strong and perhaps a bit misleading. It seems like if I return a
false, I've lost the context of what exactly didn't match in the
custom ArgumentMatcher implementation. I guess the describeTo
(org.hamcrest.Description) gets me customized messages.

Thoughts?

-- chris --

[szczepiq]

Hi,

You're right the docs might be better. ArgumentMatcher is a hamcrest
matcher and it's just a contract of Matchers. You might have a look
here: http://code.google.com/p/hamcrest

I realize completely that the point of failure in matchers is worse
than with plain assertions.

However, there are benefits if you adhere to the contract:

1. you can use your matcher also when stubbing. If your matcher throws
exceptions than you wouldn't be able to use it in stubbing.
2. you can combine your matcher with other matchers. For example if
'validArticle()' returns your matcher you can do the following:
not(validArticle()), hasItems(validArticle()). not() and hasItems()
are just some examples of existing hamcrest matchers.

You can also implement an ArgumentMatcher that just captures the arg.
Then you can get the argument and perform assertions straight in the
test code.

Cheers,
Szczepan Faber

[Chris Bartling]

Szczepan,

Thanks for you thoughts on my topic. I like your idea of capturing
the indirect output argument using the ArgumentMatcher and performing
the assertions directly in the test code. I will look into the
hamcrest matchers a bit more. Thanks again for commenting so quickly
regarding my issue.

Regards,

-- chris --

On Jan 23, 4:26 pm, szczepiq <szcze...@gmail.com> wrote:
> Hi,
>
> You're right the docs might be better. ArgumentMatcher is a hamcrest
> matcher and it's just a contract of Matchers. You might have a look
> here:http://code.google.com/p/hamcrest
>
> I realize completely that the point of failure in matchers is worse
> than with plain assertions.
>
> However, there are benefits if you adhere to the contract:
>
> 1. you can use your matcher also when stubbing. If your matcher throws
> exceptions than you wouldn't be able to use it in stubbing.
> 2. you can combine your matcher with other matchers. For example if
> 'validArticle()' returns your matcher you can do the following:
> not(validArticle()), hasItems(validArticle()). not() and hasItems()
> are just some examples of existing hamcrest matchers.
>
> You can also implement an ArgumentMatcher that just captures the arg.
> Then you can get the argument and perform assertions straight in the
> test code.
>
> Cheers,
> Szczepan Faber
>
> On Fri, Jan 23, 2009 at 5:43 PM, Chris Bartling
>

> <chris.bartl...@gmail.com> wrote:
>
> > The javadoc description for ArgumentMatcher.matches(java.lang.Object
> > argument) makes a statement about never using assertions within this
> > method and favoring returning false instead.
>

> >http://mockito.googlecode.com/svn/branches/1.6/javadoc/org/mockito/Ar...)