<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>threehv &#187; acceptance tests</title>
	<atom:link href="http://www.3hv.co.uk/blog/tag/acceptance-tests/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.3hv.co.uk/blog</link>
	<description>precision engineering for your website</description>
	<lastBuildDate>Fri, 13 Jan 2012 16:18:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Quick Tip: make it easier to debug your full-stack acceptance tests</title>
		<link>http://www.3hv.co.uk/blog/2009/03/24/quick-tip-make-it-easier-to-debug-your-full-stack-acceptance-tests/</link>
		<comments>http://www.3hv.co.uk/blog/2009/03/24/quick-tip-make-it-easier-to-debug-your-full-stack-acceptance-tests/#comments</comments>
		<pubDate>Tue, 24 Mar 2009 09:40:29 +0000</pubDate>
		<dc:creator>Rahoul Baruah</dc:creator>
				<category><![CDATA[Ruby on Rails and Software Development]]></category>
		<category><![CDATA[Writing Reliable, Bug-Free Code]]></category>
		<category><![CDATA[acceptance tests]]></category>
		<category><![CDATA[Bug-Free Code]]></category>
		<category><![CDATA[cucumber]]></category>
		<category><![CDATA[selenium]]></category>
		<category><![CDATA[specifying]]></category>
		<category><![CDATA[watir]]></category>
		<category><![CDATA[webrat]]></category>
		<category><![CDATA[Writing Reliable]]></category>

		<guid isPermaLink="false">http://www.3hv.co.uk/blog/?p=439</guid>
		<description><![CDATA[One of the issues when using Selenium or Watir to power your full-stack acceptance testing (apart from the time it takes for the test suite to run), is that stuff happens within your browser, fails and then Cucumber happily moves on to the next test before you get a chance to look at what went [...]]]></description>
			<content:encoded><![CDATA[<p><div id="attachment_443" class="wp-caption alignright" style="width: 209px"><img src="http://www.3hv.co.uk/blog/wp-content/uploads/2009/03/959622_spanners_2.jpg" alt="Spanner in the works" title="Testing" width="199" height="300" class="size-full wp-image-443" /><p class="wp-caption-text">Spanner in the works</p></div>One of the issues when using Selenium or Watir to power your full-stack acceptance testing (apart from the time it takes for the test suite to run), is that stuff happens within your browser, fails and then Cucumber happily moves on to the next test before you get a chance to look at what went wrong.  </p>
<p>If you are just using plain old Webrat you can pepper your code with <tt>puts</tt> statements so you can check the value of variables, the existence of HTML elements and the flow of code as it happens.  But with Selenium or Watir, you need to run your app separately to Cucumber, normally in a hidden, background, process, so the output of your <tt>puts</tt> statements is lost in the ether (or an empty pipe).  </p>
<p>After having a particularly annoying and hard to trace bug, that was related to an interaction between form content and javascript, I came up with an extremely simple debugging tool.  </p>
<p>Just add the following into one of your steps files: </p>
<pre><code>When /^I pause$/ do
  STDIN.gets
end
</code></pre>
<p>Then, find the feature that is causing you grief and insert a &#8220;when I pause&#8221; step at the appropriate time.  </p>
<p><code>When I do this<br />
And I do that<br />
<strong>And I pause</strong><br />
And I press "Save"<br />
Then I see my newly created object<br />
</code></p>
<p>Cucumber will power your app, poking it until it gets to the &#8220;when I pause&#8221; step.  It will then pause, waiting on STDIN for you to hit return &#8211; giving you time to open your inspector window and poke around in the form as the tests see it.  </p>
<p>In this particular case, my steps file had an incorrectly named element within it &#8211; all it took was an inspection of the element in question and I saw the error.  Hours of frustration wiped out by one of the simplest commands there is.  </p>
<p><small>Spanners by <a href="http://www.sxc.hu/photo/959622">woodsy</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.3hv.co.uk/blog/2009/03/24/quick-tip-make-it-easier-to-debug-your-full-stack-acceptance-tests/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.190 seconds -->

