<?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>James Grenning's Blog &#187; test-driven-development-tdd</title>
	<atom:link href="http://www.renaissancesoftware.net/blog/archives/tag/test-driven-development-tdd/feed" rel="self" type="application/rss+xml" />
	<link>http://www.renaissancesoftware.net/blog</link>
	<description>Blogging about Agile Development, especially embedded.  Follow me on twitter: jwgrenning</description>
	<lastBuildDate>Thu, 12 Jan 2012 00:59:40 +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>What Should you Expect from a Unit Test Harness</title>
		<link>http://www.renaissancesoftware.net/blog/archives/50</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/50#comments</comments>
		<pubDate>Tue, 06 Oct 2009 19:43:13 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Unit Testing]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[test-driven-development-tdd]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=50</guid>
		<description><![CDATA[A unit test harness’ job is to provide: A concise common language to express test cases A concise common language to express expected results A place to collect all the unit test cases for the project, system, or subsystem The facilities to run the test cases, either in full or partial batches A concise report [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/50/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>TDD and the Big Framework Part II</title>
		<link>http://www.renaissancesoftware.net/blog/archives/25</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/25#comments</comments>
		<pubDate>Tue, 30 Sep 2008 10:26:22 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Object Oriented Design]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[test-driven-development-tdd]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=25</guid>
		<description><![CDATA[In TDD next to the Big Framework we looked at a design that helps to isolate your code from the BigFramework. That article only showed half the story. Lot&#8217;s of times the big framework has the attitude &#8220;don&#8217;t call us, we&#8217;ll call you&#8221; built right in. Your code has to register somehow with the framework, [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/25/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>TDD next to the Big Framework</title>
		<link>http://www.renaissancesoftware.net/blog/archives/21</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/21#comments</comments>
		<pubDate>Sat, 13 Sep 2008 09:29:11 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Framework]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[test-driven-development-tdd]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=21</guid>
		<description><![CDATA[TDD next to the Big Framework We&#8217;re trying to create a new executable process that plugs into a pretty big services framework for a telecom system. Our code and framework are in C++. We&#8217;re test driving our design. Within a few tests, we were confronted with having to inherit from a framework class. No big [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/21/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Bug Fixes and TDD</title>
		<link>http://www.renaissancesoftware.net/blog/archives/17</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/17#comments</comments>
		<pubDate>Tue, 24 Jun 2008 16:33:08 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Acceptance tests]]></category>
		<category><![CDATA[Bug fixes]]></category>
		<category><![CDATA[Debugging]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[test-driven-development-tdd]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=17</guid>
		<description><![CDATA[Code has bugs. Finding a bug&#8217;s hiding place is a challenge. And, you know that killing a bug often breaks code in unexpected ways, hatching more bugs to discover, hunt down, and kill. If you created your whole code base using TDD, you could prevent many of these new bugs. But you have legacy code; [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/17/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

