I think it is a good idea. I have been dying to try out an idea about test environment set up through annotation. For example, you can add an annotation that a test is a selenium test, and configure the annotation so that jbehave makes sure that a Jetty server and a selenium server is up and running before the first test starts, and shuts them down after the last one finishes. I still need to work out the details but I think this is a good direction to try. In this way, the hierarchy of the test classes can be flattened, and the environment set up can be normalized.
And without annotation it will be kind of hard to do. Cheers Shane On 7/25/07, Dan North <[EMAIL PROTECTED]> wrote:
So, here's my thinking. Runtime frameworks (xstream, sitemesh, objenesis, ...)* are governed by what operations people are prepared to support in a production environment. This usually means they are several JRE versions behind, because ops people are notoriously conservative about upgrading things. Development frameworks (jmock, hamcrest, ...)* can be more adventurous because they don't have an impact on the production environment, just the developer setup. JBehave falls into this latter category, so I'm less worried about having it depend on Java 5. We could do this in stages as Mauro suggests, by having some extensions that use (and require) java 5 and others - and the core - that are still 1.4 compliant. Or we can bite the bullet - given that jbehave currently has a relatively small user base (I'm assuming here, based on the list traffic) - and move to 1.5. This would give us an opportunity to review the codebase and see where generics and annotations might help make jbehave more expressive. Plus we get hamcrest for free. What do you guys think? (Subject of course to consulting with that user base :) Cheers, Dan * That bloody Joe Walnes gets everywhere. Elizabeth Keogh wrote: 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 >
-- Shane http://www.shaneduan.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
