<?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: Tests as todos</title>
	<atom:link href="http://www.untyped.com/untyping/2008/11/05/tests-as-todos/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.untyped.com/untyping/2008/11/05/tests-as-todos/</link>
	<description>Weblog of Untyped, software developers for internet, desktop and mobile.</description>
	<lastBuildDate>Wed, 10 Jun 2009 09:20:03 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Noel</title>
		<link>http://www.untyped.com/untyping/2008/11/05/tests-as-todos/comment-page-1/#comment-133</link>
		<dc:creator>Noel</dc:creator>
		<pubDate>Mon, 10 Nov 2008 14:42:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.baseplate.org/untyping/?p=182#comment-133</guid>
		<description>&lt;p&gt;Jacob: what you do might be called functional tests
depending on the level at which you write tests.  I find it
quite difficult to code all my tests at the start of
development.  I usually do just a few and code up the rest
as development proceeds.&lt;/p&gt;

&lt;p&gt;Luis: interesting article.  Thanks.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Jacob: what you do might be called functional tests<br />
depending on the level at which you write tests.  I find it<br />
quite difficult to code all my tests at the start of<br />
development.  I usually do just a few and code up the rest<br />
as development proceeds.</p>
<p>Luis: interesting article.  Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luis Sergio Oliveira</title>
		<link>http://www.untyped.com/untyping/2008/11/05/tests-as-todos/comment-page-1/#comment-132</link>
		<dc:creator>Luis Sergio Oliveira</dc:creator>
		<pubDate>Sun, 09 Nov 2008 20:42:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.baseplate.org/untyping/?p=182#comment-132</guid>
		<description>I used this style sometimes and it worked very well, even if you&#039;re simply interrupting for the weekend. I&#039;ve heard first about this technique from &quot;Uncle Bob&quot; (&lt;a href=&quot;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&quot; rel=&quot;nofollow&quot;&gt;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&lt;/a&gt;).
</description>
		<content:encoded><![CDATA[<p>I used this style sometimes and it worked very well, even if you&#8217;re simply interrupting for the weekend. I&#8217;ve heard first about this technique from &#8220;Uncle Bob&#8221; (<a href="http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd" rel="nofollow">http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd</a>).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jacob</title>
		<link>http://www.untyped.com/untyping/2008/11/05/tests-as-todos/comment-page-1/#comment-131</link>
		<dc:creator>Jacob</dc:creator>
		<pubDate>Thu, 06 Nov 2008 10:01:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.baseplate.org/untyping/?p=182#comment-131</guid>
		<description>Hi,
&lt;p&gt;

I use automated tests in a similar todo way.
&lt;p&gt;

We use Use Cases to drive our development. When I start out coding a Use Case, I first sit down and figure out what functionality the case covers - and then express this in a set of automated tests, as close to the use case functionality as possible (I guess this is called regression tests?).

&lt;p&gt;
Then I start coding the functionality making the first test case run, and basically work my way down the list of test cases, making each run. This way I am always sure of not breaking existing user functionality, and I have a good indication of when I am done. Should I find something that is not yet covered by my test cases, I write a test case for it right away, and continue working on the code.

&lt;p&gt;
I have been pretty successful using this method to implement complex use cases. And I have a confident feeling in my stomach once I am done, plus it makes it easier for other programmers to understand the code and make changes to it.
&lt;p&gt;
Best regards,
Jacob&lt;/p&gt;&lt;/p&gt;&lt;/p&gt;&lt;/p&gt;&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I use automated tests in a similar todo way.
</p>
<p>We use Use Cases to drive our development. When I start out coding a Use Case, I first sit down and figure out what functionality the case covers &#8211; and then express this in a set of automated tests, as close to the use case functionality as possible (I guess this is called regression tests?).</p>
<p>
Then I start coding the functionality making the first test case run, and basically work my way down the list of test cases, making each run. This way I am always sure of not breaking existing user functionality, and I have a good indication of when I am done. Should I find something that is not yet covered by my test cases, I write a test case for it right away, and continue working on the code.</p>
<p>
I have been pretty successful using this method to implement complex use cases. And I have a confident feeling in my stomach once I am done, plus it makes it easier for other programmers to understand the code and make changes to it.
</p>
<p>
Best regards,<br />
Jacob</p>
]]></content:encoded>
	</item>
</channel>
</rss>
