Great, thanks Mauro. On 22 February 2012 20:19, Mauro Talevi <[email protected]> wrote:
> Yes, upon reflection, adding a method to StoryReporter makes more sense > than StepMonitor. But in essence, a similar solution, quite different > from the @BeforeStep annotation. > > I'll update the jira issue and make enhancement. > > On 22/02/2012 17:29, Graham Abell wrote: > > 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 >> >> >> >> >> > > >
