Sorry for the radio silence. I've been knee-deep in conferences and
putting together rbehave 0.1 (a story-definer and runner in ruby - let
me know if you're interested).
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:
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?
+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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
