[rspec-users] Story Runner: Readability of output with multiple params

David Chelimsky dchelimsky at gmail.com
Sun Oct 14 18:36:18 EDT 2007


On 10/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> On 10/14/07, Pat Maddox <pergesu at gmail.com> wrote:
> > On 10/14/07, Zach Dennis <zach.dennis at gmail.com> 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 at 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?

Cheers,
David


>
> --
> Zach Dennis
> http://www.continuousthinking.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list