On 1/5/12 10:10 AM, Sheldon wrote:
On 1/4/12 3:09 PM, Mauro Talevi wrote:
Hi Sheldon,
the recommended way to approach your problem would be to inject both
service builder impls and then have a parameter to determine which is
going to be used. E.g.
Given I use the [HTTP or JMS] protocol
The protocol would be stored in a member variable and use to return the
appropriate instance of your service API.
Then you can use parametrised scenarios to run the entire scenario with
different values of the protocol.
http://jbehave.org/reference/stable/parametrised-scenarios.html
Cheers
On 04/01/2012 19:37, Sheldon wrote:
I am using JBehave in a project where we test http requests to web
services. This has worked beautifully so far. Now the team is
introducing a new front end using JMS. It is designed to work as a
secondary front end to the existing web services.
For example, a customer can post a request directly to the web service
via http GET or POST, or alternatively submit a message to the JMS
service, which then will submit an http GET or POST to the web
service. The JMS service gives us the ability to prioritize and
pre/post-process requests, which is why it is being introduced.
I built the tests so that we have a collection of story files & a
single steps file. The steps file includes the following:
public class StepsFile {
MyService service;
ServiceBuilder serviceBuilder;
[a collection of @Given, @When, @Then methods]
}
The ServiceBuilder generates the service object at the appropriate
time during testing. 'service' is then queried for results (within
@Then steps).
Now that we need to handle two variations of MyService (http and JMS),
can I configure JBehave to run thru the same stories twice, but
injecting different versions of ServiceBuilder in to the StepsFile
class for each iteration? Is there a better way to handle this kind of
implementation variation?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Actually, I think the 'Parametrized Stories' feature would work. This
way I would not have to duplicate stories just because we support a new
protocol. The documentation on it is unclear on how to leverage the
parameter that is passed in to the story. Does someone know where I can
find a working example of this feature?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
I found a problem with using parametrized stories to solve the problem.
The example on the JBehave site states that a parametrized story
should be identified using the following syntax:
GivenStories: path/to/precondition.story#{0}
The problem is that the stories are not packaged in the JAR because the
reside under the test folder. To run them we use:
public class Stories extends JUnitStories {
...
@Override
protected List<String> storyPaths() {
return new
StoryFinder().findPaths(codeLocationFromClass(this.getClass()),
"**/*.story", "**/excluded*.story");
...
}
The folder structure is:
-stories
- scripts
- requirement1.story
- requirement2.story
- steps
-Steps.java
- Stories.java
The key difference is that other users of this code will have different
paths to the stories folder:
/user/<user name>/stories
Can I make GivenStories work with this set up?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
