Actually,
I would probably even change it to:
Given a user
And the user has "50" dollars
And split it into 2 steps, and wait until it is really in need of drying up
(I have those two steps at the top of like 5 scenarios or something) to
combine it into 1.
On Tue, Dec 30, 2008 at 12:30 AM, Mischa Fierer <f.mis...@gmail.com> wrote:
> Hi Erik --
>
> Interesting ideas.
>
> We're using cucumber for a medium-sized application (total steps run is
> about 550), but I hadn't really considered testing the step definitions.
>
> I have not yet noticed bugs originating from not testing step definitions.
>
> I think the following issues drive this / me being OK with it:
>
> --
>
> Our step definitions are short, and we do not have that many.
> When you think about it, there are not a whole lot of things you can do to
> a webpage, compared to the things you can do in Ruby.
>
> Webrat, email-spec and a few other steps cover most of the things that I
> need to do / check on a webpage. Therefore, many of my step definitions end
> up only involving a) setup, b) a bunch of webrat steps all at once.
>
> a) Setup: Since we use Machinist, there is very little setup to do. Most of
> these steps just go something like User.make, and then do a login or
> something.
>
> b) Most other steps are just things like "When i fill in the new user form"
> with a bunch of fill_in steps.
>
>
> W/r/t your example, I might write something like:
>
> Given "I have a "(.*)" dollar balance" do |dough|
> User.make
> User.set_balance!(dough)
> # User.balance.should == dough
> end
>
> Where set_balance! is whatever method you would use.
>
> Since the defn above is so simple, I wouldn't worry about not testing it.
> You could even add a .should into the step itself, as I have above, however
> imo step defns above 3 lines (that are not all just fill_in) are candidates
> for refactoring.
>
> Your unit test for set_balance! would then cover that step, basically.
>
> WDYT?
>
> M
>
>
>
>
>
>
>
>
> On Mon, Dec 29, 2008 at 8:17 PM, Erik Pukinskis
> <erikpukins...@gmail.com>wrote:
>
>> > The approach I like to take is to follow the guidance of the system
>> > (cucumber + rspec) every step of the way. Right now there are no
>> > passing steps, so I'd write the code for the 1st pending step, run the
>> > features and find the first thing that is missing or failing.
>>
>> This is one thing I don't get. I just started implementing steps, but
>> I feel like THAT code is all completely untested. I don't know if my
>> regular expression is correct, I don't know if it does what I think it
>> should do. What I really want to do is write something like this:
>>
>> describe "steps for withdrawing money"
>>
>> describe "Given user has a balance"
>>
>> before :each
>> cucumber "Given user has $50 dollars"
>> end
>>
>> it "should match a particular step"
>>
>> it "should create an account"
>>
>> it "should set the account balance to $50"
>>
>> end
>>
>> end
>>
>>
>> But is there such a "cucumber" method? And how do you check that your
>> regular expressions are going to the right place?
>>
>> Maybe the best thing to do is write your cucumber steps like this:
>>
>> user_has_a_balance = /user has $(.*) dollars/
>> Given user_has_a_balance do |balance|
>> ...
>> end
>>
>> And then in your spec you can do:
>>
>> user_has_a_balance.match("user has $20 dollars").should_not == nil
>>
>> How do people write specs for their cucumber steps? And if you don't
>> write specs, how do you live with the uncertainty?
>>
>> Erik
>> _______________________________________________
>> 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
