Sorry, correct - methods where we can add our calls, I'm possibly muddying the water here.
I agree, it seems to me that the reporter is well suited since it handles before/after story and after step so it's just the addition of a beforeStep(). On 22 February 2012 16:23, Brian Repko <[email protected]>wrote: > > I got the impression that the request was NOT for a @BeforeStep / > @AfterStep annotation but rather methods in either the StoryReporter or the > StepMonitor for those events. StepMonitor doesn't seem to be right place - > StoryReporter is almost there - just needs a method for before - which is > what the enhancement request is for. Or did I read that wrong? > > Brian > > > ----- Original message ----- > From: "Graham Abell" <[email protected]> > To: [email protected] > Date: Wed, 22 Feb 2012 16:05:51 +0000 > Subject: Re: [jbehave-user] Re: run code before and after each step > Hi Mauro, > > I'm surprised you think it would add a big strain during execution, in > the context of having before/after story and already having an afterStep > then it's just one more point to hook into [should you wish/need to] I > imagine in most scenarios it won't be used. Of course I'd defer to your > knowledge of the system in making that decision. > > I did have a quick look and noticed that cucumber has implemented a > before_step, not that I'm saying you should be basing your decisions on > that basis: > https://github.com/cucumber/cucumber/wiki/Custom-Formatters > > If we implemented our own StepMonitor, would we not need to implement a > lot of logic around it or could we just insert the call we need at the > performing method? > > thanks, > graham > > > On 22 February 2012 15:40, Mauro Talevi <[email protected]>wrote: > > Hi Graham, > > I'm not convinced that having a @BeforeStep is a viable solution - nor > very practical. In the spirit of the @Before/After annotations, the > annotated methods are all executed before and after each scenario, story or > set of stories (with the notable exception of the scenario annotations that > allow for the uponOutcome filter). Having a @Before/AfterStep annotation > would IMO put a big strain on the execution context without much gain, as > you'd then need to do some sort of filtering anyway in the method > implementation to avoid unwanted executions. > > If you find the StoryReporter (which reports step outcome events that are > visible to the story writer, not to the step implementer) is not sufficient > for your needs, then I'd say your need is more technical than business > focused and it would be perhaps better addressed via the StepMonitor. > There is already a "before" method, called performing(String stepAsString, > boolean dryRun), which is invoked just before the invocation of each > parametrised step. We could add a performed(String stepAsString) and you > could have your own implementation, possibly implementing StoryReporter > interface as well to give you visibility of the outcomes. > > Would this approach work for you? > > Cheers > > > On 22/02/2012 13:20, Graham Abell wrote: > > Hi Brian, > > I've raised an improvement request at > http://jira.codehaus.org/browse/JBEHAVE-721 > > I'll have a look at the StepMonitor and see if I have any joy there, > > thanks! > > > > On 22 February 2012 13:05, Brian Repko <[email protected]>wrote: > > > Graham/Marcin, > > Typically clearing out steps data is done per scenario. If not, then its > part of the test and I would clear it out as part of a when or a given so > that its known that something was "cleared". > > You could look at the StepMonitor but that is really part of step > processing - not lifecycle - its very detailed. > > That said, for the original problem, you might look at AOP for your steps. > > And we could/should look at doing beforeStep() in the story reporter. > You could log an enhancement request for that. > > Brian > > > ----- Original message ----- > From: "Marcin Zajączkowski" <[email protected]> > To: [email protected] > Date: Wed, 22 Feb 2012 00:00:02 +0100 > Subject: Re: [jbehave-user] Re: run code before and after each step > > On 2012-02-21 16:29, Mauro Talevi wrote: > > ATM only step outcomes are reported. What's your usecase for monitoring > > the before step phase? > > I will join in the discussion because I had similar problem recently. In > my case parametrised scenarios are running in a Spring context. Because > given, when, then are called by JBehave separately I had to introduce > fields in a test class to remember values. Those fields have to be reset > before each example data set (as well as mocks - some beans in a Spring > context are mocked). I can do it in "when" method, but it would be more > readable to annotate JUnit setup method also with @BeforeStep annotation > to be run before every step. > > Regards > Marcin > > > > On 21/02/2012 14:43, Graham Abell wrote: > >> Thanks, I updated to beta3 and have access to that method now. > >> > >> I've implemented my StoryReporter and see where each method gets > >> called as part of the reporting. I don't see where I can hook in > >> before a step is run though, the steps themselves call the successful, > >> pending, failed etc methods based on their outcome I guess which would > >> allow me to create the afterStep() call but not the beforeStep()? > >> > >> thanks again, > >> Graham > >> > >> On 21 February 2012 11:45, Mauro Talevi <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi Graham, > >> > >> withReporters() is a new method added in 3.6 (you can use one of > >> the betas). In 3.5.x you only have withFormats() so you'd need to > >> define your own format, e.g. > >> > >> public static final Format TXT = new Format("TXT") { > >> @Override > >> public StoryReporter > >> createStoryReporter(FilePrintStreamFactory factory, > >> StoryReporterBuilder storyReporterBuilder) { > >> > >> factory.useConfiguration(storyReporterBuilder.fileConfiguration("txt")); > >> return new TxtOutput(factory.createPrintStream(), > >> storyReporterBuilder.keywords()).doReportFailureTrace( > >> > >> storyReporterBuilder.reportFailureTrace()).doCompressFailureTrace( > >> storyReporterBuilder.compressFailureTrace()); > >> } > >> }; > >> > >> > >> On 21/02/2012 11:41, Graham Abell wrote: > >>> Hi Alex, > >>> > >>> Yeah, I have the withDefaultFormats() but I can't see a > >>> withReporters() method, I can't see it in the api either > >>> > >>> > http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/reporters/StoryReporterBuilder.html > >>> > >>> > >>> > >>> am I missing something? > >>> > >>> cheers, > >>> graham > >>> > >>> > >>> On 21 February 2012 11:00, Alex Lehmann <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> your runner class has probably a statement using new > >>> StoryReporterBuilder() and calling .withFormats and/or > >>> .withDefaultFormats() , you can add > .withReporters(yourReporter) > >>> > >>> > >>> On 21.02.2012 11:45, Graham Abell wrote: > >>> > >>> Having implemented my own StoryReporter, how do I specify > >>> that it gets used? > >>> > >>> > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list, please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >>> > >>> > >> > >> > > > > > > > -- > http://blog.solidsoft.info/ - Working code is not enough > > > --------------------------------------------------------------------- > 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 > > > > >
