Yes, I've done this now. Its certainly more explicit with distinct step methods.
I was looking at allowing my analysts to create their own permutations and combinations of scenarios, so they can add more scenarios with little or no intervention of developers. For instance, some of our our web service methods return status codes as enumerated
values. If I parameterize these enumerated values then I can write one step which can potentially generate any of these values (there could be 10 or more values). So the step could remove spaces, apply camel casing and then parse and convert to the enum. My
mock web service could then return this value to force the behaviour that I want to test.
Thanks for the help.
That makes sense :)
Oh, another thing. This is perhaps a little off-topic, but is slightly related.
My analysts have questioned the readability of the stories that have parameterized steps. They don't like the $ character - they think it makes the stories more difficult to read. I hae pointed out that this is only a problem when they write the original
story and scenarios, and when they see the output, they don't have this character and they are perfectly readable.
So, they don't currently put these in, so I have to try and decode which bits are parameterised and add the $ myself. Its a PITA!
This is interesting. When we started StoryQ, we had already been using Fitnesse on a project to enable our analysts to write acceptance tests. NBehave and Specflow are a couple of .NET BDD frameworks that support true plain-text scenarios.
We found that left to their own devices, analysts test cases got a bit unmaintainable. What we wanted for StoryQ was for developers to work together with analysts to produce stories. This way, the developer can apply refactoring, parameterisation, can ask
the analyst whenever a step narrative isn't clear enough, can break down complex scenarios into multiple ones and vice versa. The analysts shouldn't have to decide what parts of a step are parameters - maybe because your ones are actually confused about what
constitutes a parameter they are pretending to not like the $ punctuation :).
At the end of the day, the fact that StoryQ stories are checked in to source control with the rest of the codebase means that the developers can really own it. One thing I didn't like about Fitnesse was that it kept it's own revision history, which would
often be out of step with your code's changeset numbers...
I know some people see "non-technical people being able to write acceptance tests without ANY help" as a bit of a holy grail (and plaintext BDD frameworks / Fitnesse are much better at this than StoryQ), but we think that collaboration is really
important. Play to each other's strengths :)