[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/