On 10/15/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> 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.
I love this idea. I think Wincent's right that it might be a bit of
trouble to maintain things in a couple different places, and in that
case I think it makes sense just to use the current way. However I
think your idea is phenomenal for sharing steps within the code base
and standardizing stories at a very high level.
Also, I know that in my first email the step matchers didn't include
the mechanics, but I definitely thought we should combine the two.
Perhaps I didn't express that well enough. I just wanted to share my
"here's how we could solve the ugly args problem" idea, and figure out
the details later.
Pat
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
