Hi Jeff, Dan, The breaking up of matchers is already done; I haven't started including Hamcrest yet.
I love working with JBehave in Java 5, and would love it even more if it used, internally, some of the amazingness that Java 5 provides. It seems to me that our user base is (entirely?) made up of Java 5 users. It would make the matchers much simpler, too. Give me the word and I'll shift it over... :) Cheers, Liz. "Jeff Grigg" <[EMAIL PROTECTED]> wrote on 24/07/2007 02:20:21: > 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 >
