Error paths: a new scenerio or test in story runner?

Testing RSpec
1

Hi,

I think the scenario based way of defining acceptance tests is akin to
scenarios in use-cases.

In use-cases we can have a happy path with extends for error conditions
etc.

Should I create extra scenarios for my error conditions (making my
tests less understandable) or should I create a new error path story
with copied over scenarios

Aidy

2

On Thu, Aug 28, 2008 at 8:22 AM, aidy lewis [email protected]
wrote:

Hi,

I think the scenario based way of defining acceptance tests is akin to
scenarios in use-cases.

In use-cases we can have a happy path with extends for error conditions etc.

Should I create extra scenarios for my error conditions (making my
tests less understandable) or should I create a new error path story
with copied over scenarios

This was something that was bugging me for a while. I used to work w/
Fitnesse quite a bit. If you’re not familiar, check out
http://fitnesse.org. FIT (the underlying acceptance test framework in
FitNesse) is fantastic for tabular data, but it wasn’t really great at
scenario/flow-oriented structure. Rick Mugridge’s DoFixture opened the
door to some great improvements, and it was the best we had so far at
that point, but it still felt like the square peg/round hole problem
to me.

Along came rbehave (which is now RSpec’s Story Runner) from Dan N.,
and it was a great solution to the flow-structure problem (for me).
Readabilty, clarity, simplicity, etc, etc.

But then I ran into the same question you’re asking now. In the end,
FIT tables are a great solution for tabular data (which is a good
solution for expressing numerous edge cases) and Story Runner is a
great solution for flow structures. So I had this idea that we should
have a way of expressing tabular data in the context of the Story
Runner.

When I discussed this w/ Aslak, it turns out that he had been thinking
about the same problem, so we had a little brainstorming session and
arrived at a general direction. Then he actually implemented it in
Cucumber, and it’s awesome.

That said, I’d recommend taking a look at Cucumber. Let us know what you
think.

Cheers,
David

3

Hi David,
On 28/08/2008, David C. [email protected] wrote:

with copied over scenarios

This was something that was bugging me for a while. I used to work w/
Fitnesse quite a bit. If you’re not familiar, check out
http://fitnesse.org. FIT (the underlying acceptance test framework in
FitNesse) is fantastic for tabular data, but it wasn’t really great at
scenario/flow-oriented structure. Rick Mugridge’s DoFixture opened the
door to some great improvements, and it was the best we had so far at
that point, but it still felt like the square peg/round hole problem
to me.

Users see and convey things in a natural flow not in a tabular format:
Bill payments are good in a horizontal and vertical structure. For UI
testing FIT gets messy.

But then I ran into the same question you’re asking now. In the end,
FIT tables are a great solution for tabular data (which is a good
solution for expressing numerous edge cases) and Story Runner is a
great solution for flow structures. So I had this idea that we should
have a way of expressing tabular data in the context of the Story
Runner.

In my opinion, this will effect the linguistics of the Story
Runner; but I offer no alternative.

When I discussed this w/ Aslak, it turns out that he had been thinking
about the same problem, so we had a little brainstorming session and
arrived at a general direction. Then he actually implemented it in
Cucumber, and it’s awesome.

That said, I’d recommend taking a look at Cucumber. Let us know what you think.

I am currently studying it.

Aidy