Hey Everyone,
Is it good practice to call matchers from within matchers? Kinda like
this pattern:
See: committee_spec.rb · GitHub
–
Brian
On Wed, Sep 8, 2010 at 14:42, Brian K. [email protected] wrote:
Is it good practice to call matchers from within matchers? Kinda like this pattern:
David C. taught me not to invoke #should in a matcher, but
rather just answer a boolean, so I expect that, rather than matcher
using matcher, you could extract the low-level matcher behavior into
methods that both matchers would use.
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile
2010: Learn. Practice. Explore.
On Sep 8, 2010, at 2:17 PM, “J. B. Rainsberger” [email protected] wrote:
Okay thanks.
I’ll refractor matcher logic but was hoping I could be lazy and reuse /
cascade failure messages.
–
Brian
On Sep 8, 2010, at 5:19 PM, Brian K. wrote:
using matcher, you could extract the low-level matcher behavior into
methods that both matchers would use.Okay thanks.
I’ll refractor matcher logic but was hoping I could be lazy and reuse / cascade failure messages.
You can 
The reason to avoid cascading matchers is they become somewhat useless
in the negative form (should_not). If you’re NEVER going to use them
that way, you’re fine cascading.
On 9/8/10 11:42 AM, Brian K. wrote:
Hey Everyone,
Is it good practice to call matchers from within matchers? Kinda like this pattern:
No, that should be avoided. The problem is that the “internal” matcher
will throw an exception that will bubble up and be reported. Meaning
that the parent matcher (link_one in your case) is not reported and the
resulting stacktrace can be confusing. Try something like this:
include_association(expected).matches?(actual) &&
associate_one(expected).matches?(actual)
(Note, I have not tried the above but I think it should work.)
-Ben