Cool, although you might've jumped the gun a little, I was nowhere near finished ;) I was more just after some feedback about whether to continue in a JBehave branch, or just to put it into a separate JAR.
I've had a quick look, and out of the box AnnotatedPathRunnerUsingGuice isn't actually running the stories, it is however listing them in the junit results view. I'm not massively keen on your extension of AnnotatedEmbedderRunner, I was purposely trying to avoid that, trying to avoid the "baggage" that comes with the AnnotatedEmbedderRunner & BlockJunit4Runner, trying to avoid all that complexity. There are the Filterable methods on ParentRunner, that just don't affect the test run at the moment, for instance. I was trying to simplify the whole thing tbh, which when coming at it fresh 2-3 weeks ago, was a bit overly complex. It took me a 2-3 hours just to get JUnit to pick up my tests correctly. The @Configure annotation does very little when using Guice for instance, except to ignore any classes from the Modules if it's not present. (This confused me for a good 20mins until I stepped into the actual running code). I was planning on: * Trying to expand it out a bit so that the individual scenarios are displayed as passing/failing in the JUnit Results View. * Make it so stories with pendings fail properly (I think they show as having passed) * Remove the ability to change the batch/ignoreFailures/etc config as all this does is potentially break the runner if you have the wrong values. * Put sensible error messages in the stacktrace view, it doesn't actually give the reason for failure at the moment. The reason for the Maven goal, was so it could use the @UsingPaths annotation, which the way I had written the previous JUnit runner wasn't possible using that, and (again) just to simplify it. My eventual plan was to move some of the config from @UsingEmbedder into the POM and also to potentially create a new workflow for Maven just for JBehave tests. We're using JBehave for acceptance testing, so have our tests in a separate maven module to the code it's actually testing. Thanks, Dan. On 23 November 2010 20:04, Mauro Talevi <[email protected]> wrote: > Hi Dan, > > I've added AnnotatedPathRunner (a JUnit Runner) based on your > contribution. It works with any AnnotationBuilder (not just Guice) and > it uses the @UsingPaths annotation. > Check out the AnnotatedPathRunnerUsingGuice example in latest master. > > I've not added the Maven goal yet. I'd like to understand your use case > better first before adding a new goal. > > Let's separate the two issues though, as IMO they are orthogonal. > > Using http://jira.codehaus.org/browse/JBEHAVE-234 to track the > improvements to JUnit. > > Cheers > > On 22/11/2010 13:18, Dan Godfrey wrote: > > Hi, > > > > I was getting a little peeved by eclipse not showing the individual > > stories in it's JUnit results view when running JBehave, so I > > implemented a new runner for use with @RunWith that does. It works > > slightly differently to the existing JUnit integration, there's no > > need for a @Test method any more and the stories are selected using an > > annotation. But it provides useful feedback, I think, to how story > > execution is progressing and quickly highlights which stories failed. > > > > It's all sitting in the new-junit-runner branch on my github fork. I > > added a WithGuiceJBehaveRunner sample in the > > jbehave-trader-guice-example module to show it works. > > > > It's a bit embryonic at the moment, you can break it if some of the > > @UsingEmbedder flags are wrong for instance, if you execute it using > > eCobertura for coverage the reports get written into > > workspace\.metadata\somewhere\else\ and some other bits and pieces. > > > > Also, I had to write a new Maven Mojo to use the @StoryPaths > > annotation so that the XyzStories class worked from both maven and > > eclipse. However, I think it's easier to use than the current maven > > plugin, which had left me scratching my head for a good couple of > > hours when first trying to use it. > > > > What are the chances of including this, or something like it, in the > > main JBehave distro. If this is never going to happen, I'll have to > > package it up as a separate jar, but I'd rather not. Obviously I'll > > need to finish it, and fix all the edge cases first :) > > > > Thanks, > > Dan. > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
