[Warning: The following is not a question]
Cucumberists:
One of the irons in my fires is learning a little Cuke. So I try an experiment:
Feature: join
In order to get premium content
As an unregistered member
I want to enter signup information for a new account
Scenario: Proper signup
Given newb is not in the user database
And I go to /join
Okay, now that provides the standard Given suggestion, and I convert it to this:
Given /^(.*) is not in the user database$/ do |newb|
Subscription.find_by_username(newb).should_not be_nil
end
Notice the "_not be_nil". I want to see a failure; otherwise if I see a success
it might not be for the correct reason.
The failure looks like this:
Scenario: Proper signup # features/join.feature:6
Given newb is not in the user database # .../webrat_steps.rb:101
expected nil? to return false, got true (Spec::Expectations::Expect...)
./features/step_definitions/webrat_steps.rb:102:
in `Given /^(.*) is not in the user database$/'
features/join.feature:7:in `Given newb is not in the user database'
And I go to /join # features/step_definitions/webrat_steps.rb:6
Now that reflects quite a bit, but the actual .should_not only reflected
"expected nil? to return false, got true"
So let's upgrade to assert{ 2.0 }...
Given /^(.*) is not in the user database$/ do |newb|
assert{ Subscription.find_by_username(newb) != nil }
end
Not to brag (too much), but the difference is like night and day:
Given newb is not in the user database #
features/step_definitions/webrat_steps.rb:101
assert{ (not(Subscription.find_by_username(newb) == nil)) } --> false
newb --> "newb"
Subscription.find_by_username(newb) --> nil. (AssertionFailedError)
./features/step_definitions/webrat_steps.rb:103:
in `Given /^(.*) is not in the user database$/'
features/join.feature:7:in `Given newb is not in the user database'
Don't get me wrong - assert{ 2.0 } is for high-density tests of low-level code.
Not for customer-facing verbiage.
So why can't every Cucumber do-end block use RubyReflector directly? Primarily
because (with current technology), the reflector re-evaluates everything more
than twice at fault time, and if you put your money-line inside a do-end block
and it fails, the second re-evaluations might change their value and cause a
confusing output!
Ruby1.9, with its built-in Ripper, will probably make this reflection easier...
--
Phlip
http://www.zeroplayer.com/
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users