Of the options on the table, I prefer "using $placeholder values" because
then it tells me the role the value plays in the sentence. Even Pat's
version works by defining the $placeholders outside of the step.
In a "library" somewhere (we still need to define what a story/step library
is or looks like):
define :given, "a user called $name working for $company as a $role" do
|name, company, role|
...
end
In the story definition:
Given "a user called Joe working for ACME as a janitor"
Same parser. $blah just maps to (.*?) - ie. a non-greedy match of anything -
in terms of regexp.
I'm not a big fan of the alternating parameters thing - I just threw it in
for completeness based on the Smalltalky conversation we had.
On 10/14/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
>
> On 10/14/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > On 10/14/07, Zach Dennis <[EMAIL PROTECTED]> wrote:
> > > On 10/14/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
> > > > On 10/14/07, Zach Dennis <[EMAIL PROTECTED]> wrote:
> > > > > Does it add any value to even add things like "Joe" and "Acme"
> into a
> > > > > story part? It seems like that is an implementation detail of your
> > > > > story.
> > > > >
> > > > > Who cares about "Joe" or "Acme", don't you just care that you have
> a
> > > > > user who works for a company. And if that company has a particular
> > > > > trait wouldn't it be cleaner to identify the company by that trait
> > > > > rather then a name in the description?
> > > > >
> > > > > IE: Given " a user who works for a company that sells cartoons"
> > > > >
> > > > > And then in your helper you can use "Joe" and Acme"
> > > > >
> > > > > def a_user_who_works_for_a_company_that_sells_cartoons
> > > > > @user = Generate.user( "joe")
> > > > > @company = Generate.company("Acme")
> > > > > @company.employees = @user
> > > > > end
> > > > >
> > > > >
> > > > > ?
> > > > >
> > > > > --
> > > > > Zach Dennis
> > > > > http://www.continuousthinking.com
> > > > > _______________________________________________
> > > > > rspec-users mailing list
> > > > > rspec-users@rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > > >
> > > >
> > > > How do you create two users?
> > > >
> > >
> > > Given "a user joe who works for a company that sells cartoons"
> > > And "a user jim who works for a company that sells cartoons"
> > >
> > > Leave it in the description and have a well named helper method
> > > responsible for making these users.
> > >
> > > def a_user_joe_who_works_for_a_company_that_sells_cartoons
> > > create_a_user_who_works_for_a_company_that_sells_cartoons("joe")
> > > end
> > >
> > > Otherwise you will still most likely end up with a helper method and
> > > you haven't added any value except for making your story more cody by
> > > passing arguments and creating unneeded do/end blocks.
> > >
> > > Given "a user who works for a company that sells cartoons", "Joe" do
> |name|
> > > create_a_user_who_works_for_a_company_that_sells_cartoons("joe")
> > > end
> > >
> > > Another option would be to not use a helper method at all and do the
> > > real work inside of the do/end block, but no you've made your code not
> > > reusable. How likely is it that you have one acceptance test where you
> > > have a user who works for a company?
> > >
> > > Given "a user who works for a company that sells cartoons", "Joe" do
> |name|
> > > @company = Generate.company("Acme")
> > > @user = Generate.user("Joe")
> > > @company.employees << @user
> > > end
> > >
> > > I prefer hiding the implementation in well named helper methods as to
> > > not take away from the a higher level of readability that the
> > > acceptance test can accomplish. Granted, I'm shooting for the ideal,
> > > which is a customer readable/writable acceptance test.
> > >
> > > I don't think argument passing in story parts is wrong, I think that
> > > how they are being used in this thread is wrong. For example for a
> > > game you may have an acceptance test that looks like:
> > >
> > > Given "a user playing the game"
> > > When "they make a guess of", 200_000
> > > # etc...
> > >
> > > This makes more sense to me then passing in something which adds no
> > > value to the test, like the user's name "Joe"
> >
> > That's a fair argument against this example, however I think that the
> > point of the example is that there will be cases with more than one
> > variable. For example:
> >
> > Given "a ? account with ? dollars"
> >
> > We could limit ourselves to one argument per method:
> >
> > Given "a savings account"
> > And "500 dollars in the account"
> >
> > But that strikes me as less user friendly as:
> >
> > Given "a savings account with 500 dollars"
> >
> > The syntax Dan introduced earlier in this thread comes from a
> > conversation he and I had a while back about FitLibrary's DoFixture,
> > which uses Smalltalk-style keyword messages where every other cell is
> > part of a method name:
> >
> > Given "a user of type", "Admin", "making a request for", "user list"
> >
> > This would result in a call to
> > a_user_of_type_making_a_request_for("Admin", "user list"). One way we
> > might be able to tie that Zach's ideal (a normal sentence w/ lots of
> > helper methods) and make it a bit smarter would be something like
> > this:
> >
> > def a__account_with__dollars(account_type, amount)
> > account = account_types[account_type].new(amount)
> > end
> >
> > When the runner sees anything sent to Given, When or Then (or And)
> > that matches /^a\b(.+?)\baccount with\b(.+?)\bdollars$/, it would pass
> > $1.strip() and $2.strip() to this method.
> >
> > The only problem with this is that I can easily imagine such patterns
> > starting to overlap in a larger story set, potentially producing
> > unwanted results. But perhaps that's not as big a problem as I think?
> > Thoughts?
> >
> > Dan - I'm curious as to your thoughts re: this supporting the perfect
> > vision of customer-readable/writable Acceptance Tests that Zach is
> > looking for.
> >
> > Thoughts?
>
> Nevermind. Pat Maddox just suggested a better idea in another thread
> on this list:
>
> http://rubyforge.org/pipermail/rspec-users/2007-October/003704.html
>
> Cheers,
> David
>
> >
> > Cheers,
> > David
> >
> >
> > >
> > > --
> > > Zach Dennis
> > > http://www.continuousthinking.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
