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 <[email protected]>
> 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
>>>
>>>
>>>
>>
>>
