I believe our observation has been that a new Step class instance is created for each and every step method. As such, we are using the context pattern for passing state across Step classes as well as from one Step method to another within the same Step class.
On Sun, Sep 7, 2014 at 2:33 PM, Mauro Talevi <mauro.tal...@aquilonia.org> wrote: > The simplest and most important of reasons is that JBehave and other BDD > frameworks are not unit-testing frameworks. > > They are used for integration testing which by its nature is fundamentally > different from unit testing. For one thing, it spans multiple methods and > classes, while each unit test corresponds to a single method. > > > On 07/09/2014 22:28, Chad Wilson wrote: > >> I was quite confused by how jbehave and other bdd frameworks handle >> instantiation. Having familiarity with unit testing frameworks, I came in >> with the expectation that steps classes would be handled like classes in >> JUnit, one instance per method with instantiation handled by the framework. >> >> Is there a particular reason for deviating from this pattern other than >> the complexity it would require for the framework to do instantiation? >> >> Chad >> >> On 9/7/2014 12:20 PM, Mauro Talevi wrote: >> >>> The steps classes are instantiated only once per run context, i.e. for >>> the set of stories. The same steps classes are reused for all >>> scenarios. >>> >>> A context object is the recommended way to hold state in a scenario, >>> and you'd use a thread local if you are in multi-threading mode. >>> >>> If you need to reset the state before or after each scenario, you can do >>> so via the @BeforeScenario and @AfterScenario annotations, or using the >>> Lifecycle steps in your story. >>> >>> If you have a specific use case in mind, feel free to share it. >>> >>> On 07/09/2014 15:26, Anders wrote: >>> >>>> Message Title >>>> >>>> No, no problem seen, and thanks for the quick reply. >>>> >>>> The reason I ask is just to know if the state of the steps class >>>> instance is guaranteed to be available during the whole scenario. >>>> >>>> We normally use a thread local singleton context manager to hold the >>>> state of the scenario (cleared before each scenario is executed) in >>>> order to have the scenario state available to all step implementations >>>> executing in the same thread. >>>> >>>> But sometimes it is just cleaner, I think, to store state locally in >>>> fields in the step implementation class, as long as all the steps that >>>> need the info are located in the same class. >>>> >>>> Also, then I assume that the step class instances may be pooled and >>>> reused after a scenario has finished? >>>> >>>> If so, we have to be careful to not let the state leak over to the >>>> next scenario that happens to use that same instance. >>>> >>>> Or are steps class instances always recreated for each scenario >>>> execution? >>>> >>>> I’ll have to dig into our JBehave configuration a bit more to learn >>>> how this can be set up in our case. >>>> >>>> *From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org] >>>> *Sent:* den 7 september 2014 14:52 >>>> *To:* dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org> >>>> *Subject:* Re: [jbehave-dev] Step Class Instance Reuse? >>>> >>>> That depends how you configure your steps factory ... >>>> >>>> Sanity dictates that you ensure that the steps instances are unique >>>> (e.g. using the singleton mode of the dependency injection containers). >>>> >>>> Assuming this is true, then yes, the steps will always be executed >>>> from the same methods in the same class. >>>> >>>> Are you experiencing anything that may contradict this behaviour? >>>> >>>> On 07/09/2014 14:46, Anders wrote: >>>> >>>> Is it guaranteed that steps implemented in the same class will >>>> reuse the same step class instances when executed within the same >>>> scenario? >>>> >>>> Example: >>>> >>>> Scenario: My scenario >>>> >>>> Given step 1 >>>> >>>> When step 2 >>>> >>>> Then step 3 >>>> >>>> And step 4 >>>> >>>> Let’s say that step 1 and 2 are implemented in class A, and step 3 >>>> and 4 are implemented in class B. >>>> >>>> When this scenario is run, is it guaranteed that step 1 and 2 will >>>> be executed in the same instance of class A, and step 3 and 4 will >>>> be executed in the same instance of class B? >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> 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 > > >
