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.
> 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...)
> > 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 --
|
