<?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; Unit Testing</title>
	<atom:link href="http://www.renaissancesoftware.net/blog/archives/category/unit-testing/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>Manual Test is Unsustainable</title>
		<link>http://www.renaissancesoftware.net/blog/archives/206</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/206#comments</comments>
		<pubDate>Thu, 12 Jan 2012 00:59:40 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[automation]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[Unit Testing]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=206</guid>
		<description><![CDATA[Creating automated tests can be very difficult, especially when the code has gotten long in the tooth and was not created with automated tests to begin with. Many product development teams don&#8217;t invest in automated tests. They think they cannot afford them. They think their product is different and can&#8217;t be manually tested. This thinking [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/206/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Spying on Embedded &#8216;asm&#8217; directives</title>
		<link>http://www.renaissancesoftware.net/blog/archives/136</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/136#comments</comments>
		<pubDate>Fri, 03 Jun 2011 01:06:00 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Unit Testing]]></category>
		<category><![CDATA[Test-driven Development for embedded C]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=136</guid>
		<description><![CDATA[Sometimes embedded developers have to use inline assembler instructions to get better control of the processor, or to improve performance. How should we deal with those when we&#8217;re doing TDD and testing off the target? What&#8217;s the problem? The embedded asm statements cause compilation errors if the assembler instructions are not part of the off-target [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/136/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title></title>
		<link>http://www.renaissancesoftware.net/blog/archives/113</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/113#comments</comments>
		<pubDate>Thu, 24 Feb 2011 19:15:42 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[TAD]]></category>
		<category><![CDATA[TDD]]></category>
		<category><![CDATA[Test After Development]]></category>
		<category><![CDATA[Test Driven Development]]></category>
		<category><![CDATA[Unit Testing]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=113</guid>
		<description><![CDATA[In Jeff Langr&#8217;s blog, Jeff responded to an assertion (from someone Jeff calls Schmoo) that writing tests after developing a unit of production code takes less time than using TDD to create production code and its tests. For starters, I am happy the discussion is about when to write the unit tests and not if. [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/113/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Embedded Memory Constraints and TDD</title>
		<link>http://www.renaissancesoftware.net/blog/archives/72</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/72#comments</comments>
		<pubDate>Tue, 10 Nov 2009 23:33:19 +0000</pubDate>
		<dc:creator>jwgrenning</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Agile Embedded]]></category>
		<category><![CDATA[Embedded TDD]]></category>
		<category><![CDATA[Unit Testing]]></category>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=72</guid>
		<description><![CDATA[Constrained Memory is the reality for many embedded developers. Running tests in the development system won&#8217;t suffer the same memory constraints found in the target. Here are a few things to help TDD in constrained memory situations. First of all, use dual targeting so the bulk of your code is tested off-target. See my paper [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/72/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Why Test Driven Development for Embedded?</title>
		<link>http://www.renaissancesoftware.net/blog/archives/55</link>
		<comments>http://www.renaissancesoftware.net/blog/archives/55#comments</comments>
		<pubDate>Wed, 07 Oct 2009 17:02:47 +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>

		<guid isPermaLink="false">http://www.renaissancesoftware.net/blog/?p=55</guid>
		<description><![CDATA[Embedded software has all the challenges of &#8220;regular&#8221; software, like poor quality and unreliable schedules. It is just software with some additional challenges. The additional challenges do not disqualify TDD for embedded. TDD even helps with some of those uniquely embedded challenges. Leaving embedded out of it for a moment, here are benefits that TDD [...]]]></description>
		<wfw:commentRss>http://www.renaissancesoftware.net/blog/archives/55/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<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>
	</channel>
</rss>

