rspec users - Aug 2008 - error paths: a new scenerio or test in story runner?

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

On Thu, Aug 28, 2008 at 8:22 AM, aidy lewis <aidy.lewis at googlemail.com>
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 North,
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
>
> Aidy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Hi David,
On 28/08/2008, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On Thu, Aug 28, 2008 at 8:22 AM, aidy lewis <aidy.lewis at
googlemail.com> 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.
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