no offense to anyone here but all this is starting to remind me of
the days of green ASCII terminals... there's a reason gui's, wysiwyg
editors and typographic fonts were invented...
ok, nevermind, back to plain text, proportional font, character chart
art ....
:)
On Apr 21, 2009, at 6:50 PM, Nigel Thorne wrote:
Here is the same thing as a gist http://gist.github.com/99443
2009/4/22 Nigel Thorne <rs...@nigelthorne.com>
I would prefer it to be explicit what columns I am using, that way
if you have two steps that require this technique in your scenario
it still works.
Relying on an implicit 'the rest' doesn't work in that situation.
In my scenario I would like to have something like this..
Given I am logged in as <Role>
And I have a Protocol <Initial Protocol Details>
When I clone the protocol
Then the new protocol will contain <Cloned Protocol Details>
Examples:
*| Role | Initial Protocol Details ||| Cloned Protocol
Details |||
*| | Name | Urgent | Description | Name | Urgent |
Description |
| Admin| Prot1 | Y | Protocol 1 | Prot~1 | Y | Clone of
Protocol 1 |
| Admin| Prot1 | N | Protocol 1 | Prot~1 | N | Clone of
Protocol 1 |
etc.
Here I am using ||| to signify the number of columns that are
included in the above grouping. Not sure how best to indicate which
rows are header rows.
WDYT?
2009/4/22 Ben Mabey <b...@benmabey.com>
aslak hellesoy wrote:
On Tue, Apr 21, 2009 at 10:20 PM, Joseph Wilk <j...@josephwilk.net
<mailto:j...@josephwilk.net>> wrote:
On Tue, Apr 21, 2009 at 7:32 PM, Jonathan Linowes
<jonat...@parkerhill.com <mailto:jonat...@parkerhill.com>> wrote:
>
> On Apr 21, 2009, at 1:57 PM, Joseph Wilk wrote:
>
>> What you really want is an examples table that is embedded in a
step
>> (different from a step table, maybe by keyword?) that causes
the step to be
>> run multiple times for each of the values. So rather than using
placeholders
>> we embedded a Examples table in the step.
>
>
> like this?
Not quite, I was thinking of running the whole scenario for the
examples step table rather than just the step.
However I really like Ben's suggestion of a sub-table
(http://gist.github.com/99255).
I think it would be conceptually easier for a non-technical user to
grasp than my first suggestion which makes it a big win for me.
Thanks a lot for all the suggestions so far. I like Ben's subtable
too.
In the example: "I should be presented a menu with <Meat Options>"
I assume the step definition would be:
Then /I should be presented a menu with/ do |meat_hash|
# meat_hash has the following value the 2nd time (Jewish):
{'Pork'=>'N', 'Lamb'=>'Y', 'Veal'=>'Y'}
end
However, having the <Meat Options> as part of the step would be
inconsistent with how the regexp matching is currently working.
Here is an alternative: http://gist.github.com/99376
The idea is that we add a new kind of multiline argument in
addition to pystrings and tables: Hash. This is
done using the familiar <> delimiters as a multiline argument.
What's inside it has no significance other than documentation.
The keys of the hash would be the same as the Examples table header
*minus* the columns that are referred in other steps.
In essence it achieves the same as Ben's, but relying on a
convention (removing referenced columns) rather than introducing
a new, more complex table markup.
WDYT?
Interesting.. so your meat_hash was derived from the columns of the
table that were not used previously in the scenario? Meaning, that
is why Religion was not part of your meat_hash.
That makes sense, and.. since the scenario outline is parsed before
any of the examples are ran through that convention could be
maintained no matter what order the delimiters appear in the
scenario. (Just thinking out loud here...)
Yeah, I like it. I also agree with Matt about meat_hash. All this
meat_hash talk is making me hungry...
However, what if people wanted multiple hashes? Subtables would
allow for this but a single hash solution would not. FWIW, here is
a very contrived exampled:
http://gist.github.com/99424
I agree that the sub-table is probably adding too much complexity,
especially since we have a simpler alternative and no real use
cases for it yet. Basically, you can ignore that last gist, I was
just experimenting with contrived use cases. :)
-Ben
Aslak
--
Joseph Wilk
http://blog.josephwilk.net
>
https://rspec.lighthouseapp.com/projects/16211/tickets/149-step-
outline
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org>
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org>
http://rubyforge.org/mailman/listinfo/rspec-users
----------------------------------------------------------------------
--
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
