Hi, since you have access to the code we (codecentric) left, the class you are looking for is called ScenarioContext, if my memory serves me right.
Kind Regards -- Andreas Ebbert-Karroum (mobil) Am 05.11.2013 16:14 schrieb "Hans Schwäbli" <[email protected]>: > Enrique, I was asking for information not demanding a feature. > > Can you guarantee that that page object implementation works for everyone > or works at all? > > What if JBehave instantiates new Steps from time to time? The dynamic > variables would be gone. When implementing dynamic variables JBehave > framework has to be considered since it runs the steps in its own way and > you have not much control over it, whether it instantiates new Steps or > uses the same. Is there a contract for this? If not, what if JBehave > implementation is changed and this solution does not work anymore? I think > it is worth thinking a bit about the consequences. > > And what if you run parallel stories. Is it guaranteed that each run will > have its own step objects or will they be shared? > > What about life cycle issues? What if you want to clean all dynamic > variables after each story has run for instance? That would require some > design and being embedded in the story run machine. > > And is it such a far fetched thing to suppose that JBehave might support > dynamic variables for the runtime if it already supports variables which > are set at "compile" time? > > As I said, I am not demanding anything, but I think a few thoughts about > this (or questions how others have done it) are no bad idea before > implementing dynamic variables. > > > 2013/10/31 Jorge Pombar <[email protected]> > >> We also have several scenarios where the input for the scenarios are >> determined at runtime. >> >> >> >> I think Paul offered a good solution, create a variable in the pageObject >> and set it (by the When step) then you can get it (on the Then step) for >> verification (I think we’ll give this approach a chance) >> >> >> >> Another solution is to have a static map where you set it and then >> retrieve it when needed. This is what we have implemented and it works for >> us. >> >> >> >> Thanks, >> >> Enrique >> >> >> >> *From:* Hans Schwäbli [mailto:[email protected]] >> *Sent:* Thursday, October 31, 2013 8:24 AM >> *To:* [email protected] >> *Subject:* Re: [jbehave-user] Support for dynamic variables? >> >> >> >> I see. So there is no use looking for a existing JBehave feature for this. >> >> >> >> I meant dynamic variables which are set and used at runtime. There are >> cases where one has to automate tests on non-deterministic test data (I >> mean the data of the application under test). >> >> >> >> A "life cycle" of these variables might be an issue in future. Currently >> I cannot tell you a real world use case for it. But I think there might be >> the need to configure the scope of such dynamic variables to be existing >> per stories, per story or per scenario. This would require a close >> integration into JBehave execution procedure. >> >> >> >> The easiest could be to store the variables for the whole execution and >> to clear them if needed in steps annotated with @BeforeStory for instance. >> >> >> >> I have to think a bit on how I could solve this in a suitable and good >> way. >> >> >> >> 2013/10/31 Mauro Talevi <[email protected]> >> >> Typically you would define an API to access these variables. This is >> something that you cannot really generalise. >> >> If on the other hand you know these variable at execution time, you could >> pass them as system properties in the jbehave maven goal or ant task. >> >> >> >> On 31 Oct 2013, at 11:12, Hans Schwäbli <[email protected]> >> wrote: >> >> > For some stories and scenarios I need dynamic variables which are >> determined at runtime. >> > >> > Example: I want to store the balance of an account, do some >> transactions and then expect that the balance is increased by 1000 for >> instance. If your test data are not deterministic you need such approaches. >> > >> > Is there a JBehave feature for this, storing such dynamic variables at >> runtime and accessing them at runtime across scenarios and stories? >> > >> > Or do I have to implement that myself in my steps? >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > >
