Thank you Andreas. It is named "StoryContext" and is used for compile-time properties and runtime properties..
It has a storage for properties and supports to bundle these properties into predefined Java business objects. I am not sure if I will use that bundle solution or just plain keys with prefixes and their values. The simple solution which acts like a re-settable property registry would then look something like the code below. I think I would like to use that for runtime properties. Handling compile-time properties could be solved maybe with Apache Commons Configuration or something like that. import java.util.HashMap; import java.util.Map; /** * Manages properties which can be set and get at runtime. </br> * Internally ThreadLocal is used so that each Thread has its own instance. */ public class DynamicProperties { private static final class ContextLocal extends ThreadLocal<DynamicProperties> { @Override protected DynamicProperties initialValue() { return new DynamicProperties(); } } private static final ThreadLocal<DynamicProperties> context = new ContextLocal(); private Map<String, String> properties = new HashMap<String, String>(); public static DynamicProperties instance() { return context.get(); } private DynamicProperties self() { return instance(); } public void reset() { context.set(new DynamicProperties()); } public void put(String key, String value) { self().properties.put(key, value); } public String get(String key) { return self().properties.get(key); } } 2013/11/5 Andreas Ebbert-Karroum <andreas.ebbert-karr...@codecentric.de> > 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" <bugs.need.love....@gmail.com > >: > > 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 <jorge_pom...@symantec.com> >> >>> 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:bugs.need.love....@gmail.com] >>> *Sent:* Thursday, October 31, 2013 8:24 AM >>> *To:* user@jbehave.codehaus.org >>> *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 <mauro.tal...@aquilonia.org> >>> >>> 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 <bugs.need.love....@gmail.com> >>> 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 >>> >>> >>> >> >>