Details
New Feature
Resolved
Major
Description
In acceptance/integration tests is often common to have a lightweight container (Pico, Spring, Guice, etc ...) to configure the tests with.
A container-supported Steps instance should be composable (either via constructor or setter dependency injection) with components configured in the container.
Each container support will be contained in a separate optional module.
We start with Pico support, with other containers to follow.
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.1 [ 14547 ] | |
| Fix Version/s | 2.2 [ 14670 ] |
Mauro Talevi
made changes -
| Fix Version/s | 2.2 [ 14670 ] | |
| Description |
In acceptance/integration tests is often common to have a lightweight container (Pico, Spring, Guice, etc ...) to configure the tests with. Steps need to access the components configured in the container. We should provide an container facade layer that allows to retrieve configured components by type and/or key and provide ContainerSteps classes that users can extend if they need container support. |
In acceptance/integration tests is often common to have a lightweight container (Pico, Spring, Guice, etc ...) to configure the tests with. A container-specific Steps instance would be injectable (either via constructor or setters) with components configured in the container. The LCD approach may turn out to be insufficient, so that these container adapters for Steps should use container-specific features. |
Mauro Talevi
made changes -
| Assignee | Mauro Talevi [ maurotalevi ] |
Mauro Talevi
made changes -
| Affects Version/s | 2.0 [ 14456 ] | |
| Assignee | Mauro Talevi [ maurotalevi ] | |
| Fix Version/s | 2.5 [ 15850 ] | |
| Affects Version/s | 2.4 [ 15664 ] | |
| Summary | Add lightweight container support for steps | Allow Steps dependencies to be composable via PicoContainer |
| Description |
In acceptance/integration tests is often common to have a lightweight container (Pico, Spring, Guice, etc ...) to configure the tests with. A container-specific Steps instance would be injectable (either via constructor or setters) with components configured in the container. The LCD approach may turn out to be insufficient, so that these container adapters for Steps should use container-specific features. |
In acceptance/integration tests is often common to have a lightweight container (Pico, Spring, Guice, etc ...) to configure the tests with. A container-supported Steps instance should be composable (either via constructor or setter dependency injection) with components configured in the container. Each container support will be contained in a separate optional module. We start with Pico support, with other containers to follow. |
Mauro Talevi
made changes -
| Status | Open [ 1 ] | In Progress [ 3 ] |
Hi David,
creating a scenario wrapper that does not use a hierarchical paradigm may be a useful enhancement but it's a separate concern from the ability to compose steps classes. You may want to create a separate issue for that.
Show
Mauro Talevi
added a comment - Hi David,
creating a scenario wrapper that does not use a hierarchical paradigm may be a useful enhancement but it's a separate concern from the ability to compose steps classes. You may want to create a separate issue for that.
Mauro Talevi
added a comment - Hi David,
creating a scenario wrapper that does not use a hierarchical paradigm may be a useful enhancement but it's a separate concern from the ability to compose steps classes. You may want to create a separate issue for that.
Mauro Talevi
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
I created a pretty nice way to break the JBehave Inheritance Hierarchy that isn't framework specific. Instead of inheriting from Scenario, it allows you to delegate to a class that does so. If something like this were integrated directly into JBehave, then framework-specific code would be minimal:
http://blog.davidron.com/2009/12/breaking-jbehave-inheritance-hierarchy.html
My company uses this code to run Jbehave tests inside of a standard spring container. It works with both annotation-driven spring classes and with test classes that extend AbstractTransactionalSpringContextTests.
It also supports finding the steps configuration file by name (string) or class name.