Thanks for the clarrification of your intent for the comment. After
reading the linked threads I have the following questions/comments:
1) All the responses to sharing story content get "use ruby" as the
response.
2( I understand you appear to find this adequate. I do not.
3) Should I open a new ticket for my suggestion or just add to the
existing ticket?
What I would like to see is something like a "feature" that is just
for reuse. The current scenario and feature in cucumber combine 2
concepts: the definition of a scenario/feature and the execution of a
scenario/feature. This is like being unable to create a function
without calling it immediately in place. While I appreciate for the
top level of control this is convenient and natural for the reader.
It largely prevents reuse. I would like a new keyword that just
defines a sequence of steps as one step. I want step definitions in
the story language.
StepGiven: Log in as admin
Given: I am registered as admin, David, secret
When I log in with David, secret
Then I should see "Welcome David"
And I should see a link to "Manage Content"
Scenario: Admin clicks on "Manage Content"
Given Log in as admin
When I click on "Manage Content"
Then I should see a link to "Go back to menu"
This would only execute the scenario once, unlike GivenScenario. You
can place StepGiven, and StepWhen, and StepThen in any file and they
only define steps that can be used by other content. They can
reference steps created in either ruby or story language. You can
choose to present the nested steps or not. In HTML output it could be
expanded and collapsed. In text output there could be an option to
limit output nesting depth.
To make this fully functional there should be a Require: that allows
files with step definitions to be required, solving most of your
shared content objections for file management. Content can be
required and need not be executed unless so desired and referenced by
a scenario.
It would require the title for the Steps to be regex expressions and
variables dealt with in stories I guess. But, when presenting to
customers having shared content is important for validation of the
specifications. For acceptance testing one level may be enough, but
for specifications there needs to be nesting and shared content that
can be verified by the customer or their non-programmer representative
or domain experts. For reference the project I hope to use this on is
expected to be 50-100 technical people. We are going to really need
readable specs for business logic, UI, and so on.
What do you think?
Michael
On Sep 25, 2008, at 8:52 AM, David Chelimsky wrote:
On Thu, Sep 25, 2008 at 9:42 AM, Michael Latta <[EMAIL PROTECTED]> wrote:
The problem I have with this reasoning is that the point of plain
text
stories is to get more stakeholder involvement. Being able to
express
shared content in plain text allows the non-programmer reader to
verify more
details (for example UI interactions within a high level story). I
would
like to be able to express the high level intent of the scenario
and then
(still in readable english like text) describe the UI interactions
for each
step, or the business logic details, or what ever should be
verified by the
customer to be correct about the details. Saying "you can always
use ruby"
assumes the audience is programmers.
I think you misunderstand what I wrote. I made no such assumption. I
said very specifically that this was audience dependent and that if
you're audience is customers you can look at it one way, but if it's
just developers you can use the Ruby tools. I can see why you might be
confused by "If you're a developer" rather than "if your audience is
all developers," but that was the intent.
In terms of ways of sharing content, there is some interesting
discussion going on around Cucumber, which will replace Story Runner.
Have a look at these:
http://blog.davidchelimsky.net/2008/9/22/cucumber
http://rspec.lighthouseapp.com/projects/16211/tickets/3
Please feel free to join the conversation there, or on this list.
Cheers,
David
In most cases this is not the case for
several levels of detail on the kinds of projects I am working.
Michael
On Jun 24, 2008, at 2:31 PM, Rick DeNatale wrote:
On Tue, Jun 24, 2008 at 3:00 PM, David Chelimsky <[EMAIL PROTECTED]
>
wrote:
On Jun 24, 2008, at 1:54 PM, Yi Wen wrote:
In David's presentation @ RailsConf, he has this example:
Story: measure progress towards registration goals
As a conference organizer
I want to see a report of registrations
So that I can measure progress towards registration goals
Scenario: one registration shows as 1%
Given a goal of 200 registrations
When 1 attendee registers
Then the goal should be 1% achieved
Scenario: one registration less than the goal shows as 99%
Given a goal of 200 registrations
When 199 attendees register
Then the goal should be 99% achieved
Notice that Given part is exactly the same for both scenarios.
Does it
possible to DRY up it a little bit by putting Given up to right
after
Story part? Or it is just too crazy?
Depends on who the audience is. If you're using plain text w/
customers,
yes it's crazy. The whole point is to keep things non-programatic.
If you're a developer, then write the stuff in pure Ruby and you
have
plenty of language-tools to DRY things up to your heart's content.
Or leave the plain-text MOIST* and rejoice in the fact that the
step can be
shared and therefor DRY things up.
*MOIST = More Obvious In Simple Text
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
_______________________________________________
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
