[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

Reply via email to