On 24 Nov 2010, at 09:35, Dan Godfrey <[email protected]> wrote:
> 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.
Happy to accept such improvements in jbehave branch.
> 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
Oops, I'll have another look :-)
>
> 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.
There may be a case for changing the runner impl, possibly on both. Let's
evaluate pros and cons.
> 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
>
>
>
