Show me the response

I'll avoid the introductions to Cucumber and just jump right into this topic.

Often when developing a feature scenario, the Given/When/Then steps follow links, click buttons, etc. landing on a page, and then assert specific conditions to validate the results. While developing these steps, and especially when things go wrong, you might want to see the current html response to the prior step's request.

For example,

Given I am logged in as a user

When I follow the "My Profile" link

Then I should see "Hello Jon"

So lets say the 3rd step fails and you don't know why. Sure, you can plow through the traceback and logs but that can be a pita especially on large pages with deeply nested DOM, especially if the problem might be obvious if you could just see the damn page.

Solution: Add a "(show me)" step, which opens a browser window and shows me the page:

Given I am logged in as a user

When I follow the "My Profile" link

Then (show me) 

Then I should see "Hello Jon"

Now you can see the response page, and realize, perhaps, it actually says "Howdy Jon" (or whatever). Then you can either fix the code, or fix your story. 

This is not a real step in the true nature of Cucumber's business DSL, but a utility instruction, implemented as

Then /^\(show me\)$/ do

  show_me

end

and

def show_me

  name = response.request.request_uri.gsub(/[\/\#\?]/,'-')

  File.open(RAILS_ROOT + "/public/cucumber/#{name}.html", "w"){ |f| f.puts response.body }

  system "open -a Firefox.app http://localhost:3000/cucumber/#{name}.html" 

end

show_me dumps the current response page into an html file and opens it in a browser. The name of the html file is derived from the current request_uri, so you can have multiple show_me steps in a scenario (provided the uri's are unique or your scenarios run slow enough that the page is loaded before the next one is dumped). 

Note, due to how Cucumber is implemented, the step can be used after any other step, if you just say

And (show me)

 This way you dont have to think about whether it's placed after a Given, When or Then, as I'll often cut/paste the line as I work my way down through a scenario.

This is also useful, for instance, when writing (or refactoring) scenarios for existing features and you want to find the specific DOM selector for a tag. Once opened in the browser, you can examine the DOM (with FireBug or whatever).

Cross-browser Checking

You can easily change the browser, maybe even add a step, "(show me in $browser)", to pick Firefox, Safari, etc. and use it as a poor-man's cross-browser testing. Sure, it's not Watir or Selenium (which I've haven't played with yet), it's just a manual visual inspection but as a temporary sanity check, it's not all bad.

HTML Validation

While I'm at it, I'll also mention a couple of other utility steps that help me validate the html on a page. (Reminder, mine is a Rails app).

The first uses ruby_tidy via the rails-tidy plugin. 

Then /^the page html should be valid$/ do

  # using ruby_tidy

  assert_tidy

end

This uses the assert_valid_markup plugin, which validates your (X)HTML against the W3C Validator web service. Use it sparingly, as it can be slow.

Then /^the page html should be w3 valid$/ do

  # using assert_valid_asset plugin

  assert_valid_markup( response.body )

end