This strikes me as a really good idea: Making the Matcher creation methods
static for Java 5 and external access, and splitting them into multiple
classes. One could still provide convenient Java 1.4 access by having
UsingMatchers methods that forward to all the *Matchers classes.
(I'm currently working towards introducing JBehave as a BDD tool in several
project heavily into JUnit usage. So I want to be able to use JBehave
assertion logic from JUnit tests. I'm currently doing this with a class I
wrote, "public abstract class UsingMatchersTestCase extends TestCase" that
contains all UsingMatchers method signatures, and forwards all calls to a
local instance of UsingMatchers. It's working pretty well for me. ...at
least so far. ;-)
-- JeffGrigg
----- Original Message -----
From: "Dan North" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, April 18, 2007 8:33 AM
Subject: Re: [jbehave-dev] Re: Splitting UsingMatchers
[...]
fwiw I agree about breaking out the matchers and making them
statically-importable. Maybe now is the time to start looking at hamcrest
compatibility, and having the wider conversation about how we can leverage
the java 5 features in a gracefully-degrading way.
--- Mauro Talevi wrote:
+1.
Perhaps we could also make the methods static. That way, folks on JDK1.5
can use static imports and not have to extends UsingMatchers, while folks
on JDK1.4 can keep on doing as before.
Also, if static the split matchers can be invoked directly rather than
via the facade of UsingMatchers.
Cheers
Elizabeth Keogh wrote:
Hi all,
I'm trying to add Collection and Array matchers to UsingMatchers.
This is now a really, really big class!
I'd like to split it up and delegate to the package-accessible splits,
because this will make it easier to maintain.
The split I envisage at the moment is:
CustomMatcher (move to top level)
UsingEqualityMatchers (eq, isNull, isA)
UsingCollectionMatchers (collectionContaining)
UsingArrayMatchers (arrayContaining)
UsingLogicalMatchers (and, or)
UsingStringMatchers (contains, startsWith, endsWith)
UsingExceptions (pending, fail, todo, runAndCatch)
Ensure (ensureThat)
I think this will also be far easier to extend than what we have now,
even if we do end up rewriting Hamcrest.
I have also added the describe(Object arg) method to CustomMatcher,
which returns arg.toString() by default. This allows me to do neat
things like "Expected a collection containing <4> but got an ArrayList
[5, 6, 7]".
What do you think?
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
