Am 02.06.2013 20:23, schrieb Mauro Talevi:
Hi Sebastian,
there is a balance to be struck between supporting a feature and the way
one can do in several DI containers. I'd rather look for a generic
solution that rely on features of the DI containers.
That is my expected answer to my question. It is not that easy to
implement this in general.
For example, if we created a context object that could be declared in
each container at singleton scope,
this single context could manage several scopes (rather than the
containers themselves).
Interessting idea. But i think it missing one point. The Focus is not on
thinks that get injected in step-instances (injection in step-instance
or not out of focus but it is not the main focus). The main focus lies
on injections in application-code that are normally in some scope (let's
say SINGLETON or SESSION) and now i want to test it.
Let me try to create a small example. I will be back soon and post a
link to it.
-- Sebastian
Then we could use @Before/@After annotations to reset the state of each
context-managed scope.
Eg,
class Context {
enum Scope { SCENARIO, STORY};
void add(String name, Object o, Scope toScope);
Object get(String name, Scope fromScope);
void reset(Scope scope);
}
class ScopedLifecycle {
Context context; // injected by container
@BeforeScenario
public void reset(){
context.reset(Scope.SCENARIO);
}
}
Would this approproach work for you?
Cheers
On 02/06/2013 19:56, Sebastian Sickelmann wrote:
2013/6/1 Mauro Talevi
<mauro.tal...@aquilonia.org>:
Hi,
first of all thanks for the contribution of the prototype and the
suggestion
of the new feature.
Here are some initial comments:
- if I can resume your goal, it'd be to provide a context map -
scoped at
scenario or story level - via which to share objects in the
implementations
of the steps.
That was not my intension but a solution to JBEHAVE-921 as i had
understand it a few days ago. But i think i missed the intenssion of
JBEHAVE-921.
- as such it's not something that is necessarily tied to feature of
Guice,
although DI containers may support in different ways.
My idea was to have DI-Scopes at the Scenario- and Story-Levels. So
that i can test a system, that is Guice-enabled, more easily with
jbehave. I don't have trouble with shared mutable state between
Step-Instances, as Barrie McGuire in JBEHAVE-921, but i need to manage
"reset of state" at story- and scenarion-level for my instances more
easily. Normally these instances are in SINGLETON-Scope in the real
application, .
Now, taking a step back, would it be conceptually equivalent to
defining a
context map object (which different keys for different scopes) and
simply
declaring it and having it available in the DI containers?
The question i have is, what is with other DI containers? Do they also
have Scopes?
What would be the procedure to bring such new concepts to jbehave if
it could be implemented for all supported DI-containers?
In this case, it could be in principle supported entirely by the user
configuration (albeit using some common context classes).
I'd like to understand better the use case that's driving this
requirement.
Ok. I also think that's the best way to unterstand it. So here is my
usecase:
I ran into same problem while I created test cases for a guice-enabled
application.
I got multiple step-instances that need to share state to implement
the teststeps.
So i created the step-instances with Guice(that was before i detected
jbehave-guice)
and let inject my system under test to the step-instances.
But i run into problems at Scenario and Story-Boundaries, Where i need
to reset
my system-state. So i started to implement Scenario-Scope with Guice.
Hope that help to understand my requirement. It has nothing to do with
JBEHAVE-921.
-- Sebastian
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
