How to get started with cucumber and assert{ 2.0 }


#1

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