> (on a aside note: what would examples look like if both ideas get
> implemented? I'm afraid it'll be confusing.)
>
> > > I agree that in defining the rules that define the behaviour those
> > > situations are equivalent.
> > >
> > > However, as the examples _are the tests_ we need both as we need to
> test
> > > both those scenarios so the testers have confidence the feature is
> working
> > > in all situations.
>
> Given I am a <role>
> And I am on the entity list screen
> When I <action> a new or expired entity
> ...
>
> I realize the three Then steps become "double" steps, too.
> Doesn't really scale when you have more than two states...
>
oh ok... no. The 'Then' steps are still single steps.. the scenario gets
executed more times...
so if you had
Example:
| X | Y |
|[a|b]|[c|d]|
The scenario would be run 4 times:
{X=>"a", Y=>"c"}
{X=>"a", Y=>"d"}
{X=>"b", Y=>"c"}
{X=>"b", Y=>"d"}
I'm really just trying to find a succinct way to express a bunch of
combinations so more paths are covered by the test.
What bothers me is that if I keep applying techniques to reduce the number
of lines it takes in the example to explain all the combinations in a
succinct way.. the next feature would be to have precidence rules for the
examples lines... and then you in effect have a rules engine! ... maybe that
is the natural extension of the examples table.. here are the rules that
goven this scenario!
If that is the end result.. maybe there is a better way to express it than
as a table (although I am having some good wins with tables at the moment)
WDYT?
> I'm out of ideas, time for someone else to chime in :)
>
> All opinions appreciated!
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
