<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Retrofitting Cucumber to an existing codebase</title>
	<atom:link href="http://www.testjutsu.com/retrofitting-cucumber-to-an-existing-codebase/feed" rel="self" type="application/rss+xml" />
	<link>http://www.testjutsu.com/retrofitting-cucumber-to-an-existing-codebase</link>
	<description></description>
	<lastBuildDate>Fri, 03 Dec 2010 17:00:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Justin Hunter</title>
		<link>http://www.testjutsu.com/retrofitting-cucumber-to-an-existing-codebase/comment-page-1#comment-607</link>
		<dc:creator>Justin Hunter</dc:creator>
		<pubDate>Fri, 03 Dec 2010 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.testjutsu.com/?p=293#comment-607</guid>
		<description>Ben,

Thanks for taking the time to write about your lessons learned!  I&#039;ve dealt with similar issues in explaining how to design combinatorial test cases (pairwise, etc.)  It tends to be easier to do, conceptually, in situations where all the functionality is new.  It is more difficult for testers to understand how to design pairwise and other combinatorial tests for a mix of old functionality and new.

I particularly liked your insight about: &quot;Given that there is the potential for test to ‘just light up green’ when you write them, I’ve also found it a good idea to write checks that fail so you know they’re actually doing something, then correcting them – it sort of keeps the spirit of BDD/TDD even if you’re not driving any development just at this point.&quot;  That&#039;s a clever and pragmatic suggestion.

- Justin Hunter</description>
		<content:encoded><![CDATA[<p>Ben,</p>
<p>Thanks for taking the time to write about your lessons learned!  I&#8217;ve dealt with similar issues in explaining how to design combinatorial test cases (pairwise, etc.)  It tends to be easier to do, conceptually, in situations where all the functionality is new.  It is more difficult for testers to understand how to design pairwise and other combinatorial tests for a mix of old functionality and new.</p>
<p>I particularly liked your insight about: &#8220;Given that there is the potential for test to ‘just light up green’ when you write them, I’ve also found it a good idea to write checks that fail so you know they’re actually doing something, then correcting them – it sort of keeps the spirit of BDD/TDD even if you’re not driving any development just at this point.&#8221;  That&#8217;s a clever and pragmatic suggestion.</p>
<p>- Justin Hunter</p>
]]></content:encoded>
	</item>
</channel>
</rss>
