On 10/15/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
> El 15/10/2007, a las 5:49, [EMAIL PROTECTED] escribió:
>
> >>> Actually a parser for this would be quite simple
> >>
> >> Dead simple. It would also allow us to do away with methods like
> >> Given, When and Then, which some people have objected to (because of
> >> the capitalization), because the stories are no longer expressed
> >> directly in Ruby. Internally, the parser could use a StepFactory
> >> to do
> >> things like create_given, create_when, etc (or however we decide to
> >> name these).
> >>
> >> I'm really excited about this idea!
> >>
> >> Cheers,
> >> David
> >
> > I'm working with a customer who's got a decent-sized Rails app with
> > absolutely 0 lines of test code. The first thing we'll be doing is
> > writing a bunch of user stories together. I'm going to do it in this
> > new format, so I ought to have at least a basic implementation in a
> > couple of days as a matter of necessity :)
>
> I've read this thread with some interest but I don't really get
> exactly what's being proposed, in the sense of how this would look in
> practice.
>
> - The customer/client (not necessarily with any programming
> knowledge) writes the stories in a format which is (almost) plain text.
Why almost? Because there is required syntax? We're asking them to be
able to write this:
Story: employee accrues 1 day per month
As an employee
I want to accrue 1 day per month during my first year
So that I can replenish my self
Scenario: accrual after one month
Given an employee
When employee has worked 1 month
Then employee should accrue 1 day vacation time
Scenario: accrual after 2 months
Given an employee
When employee has worked 2 months
Then employee should accrue 1 days vacation time
> - The developer then writes custom "step matchers"; where do they go?
TBD. Probably in a directory under stories named steps or step_matchers.
> - How much of parsing can be generalized and done by RSpec itself
> without requiring the developer to spend too much time writing the
> matchers?
At first this will be all on the developer. But this actually solves
the problem of sharing steps across stories. I'm sure that, as we gain
experience with this, people will create Step Libraries (coined by Pat
Maddox earlier in this thread, I believe) that would serve general use
well. I can especially see this evolving in the area of rails
controllers, though I would want to see them be higher level than
this:
When admin gets /users
I'd much rather see this:
When admin navigates to the user list
In this case, the step would look in a Hash like this:
paths = { 'the user list' => '/users' }
This would mean keep the stories at the right level of abstraction and
make them easier to maintain if/when paths change.
>
> Basically the idea of neat and readable stories is very appealing,
> but I don't really understand the mechanics of what's being proposed.
> Can someone please clarify?
There are some pieces missing. Pat's initial description (the
beginning of this thread) recognizes Steps, but I'd like to see them
include the mechanics. Something like this:
matcher = StepMatcher.new("/^(.*) navigates to (.*)$") do
login_as arg1
get arg2
end
Then the runner would translate this:
When admin navigates to the user list
to this:
find_when('admin navigates to the user list')
which would find the matcher defined above and eventually do this:
matcher.run_step 'admin navigates to the user list'
at which point 'admin' and 'the user list' would be extracted and
thrown at the block.
Obviously there are pieces missing here, but I think that this could
prove very easy to use.
Cheers,
David
>
> Wincent
>
>
> _______________________________________________
> 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
