<?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: The ten pros and cons of unit testing</title>
	<atom:link href="http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679/feed" rel="self" type="application/rss+xml" />
	<link>http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679</link>
	<description>A blog about life, the universe and everything else</description>
	<lastBuildDate>Fri, 30 Jul 2010 12:23:51 +0200</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Toby Ho</title>
		<link>http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679/comment-page-1#comment-1461</link>
		<dc:creator>Toby Ho</dc:creator>
		<pubDate>Thu, 06 Aug 2009 14:04:19 +0000</pubDate>
		<guid isPermaLink="false">http://swizec.com/blog/?p=679#comment-1461</guid>
		<description>Nice write up. Like your blog. IMHO, Integration testing is just hard to automate, and you have to find the right cost vs benefit to do it. However, the TDD camp - in general - are not so big on integration testing, they are mostly concerned about unit testing THEIR code, and usually use mocks to mock away the integration points. This makes tests easier to write and run faster, but unit tests are not as useful as integration tests. Their thing though, is that doing TDD style coding forces you to write well-decoupled code, and the testing is only a part of it - in other words, testing isn&#039;t their only goal. But, I think after you get to a certain point of experience, you can probably make the right decision as to what to decouple and what not to.

I don&#039;t write tests for UIs anymore. I change the design all the time, so what&#039;s the point? Besides, designing UIs is a visual and interactive process, and there&#039;s just no way to automatically test whether a UI looks nice or is easy to use.</description>
		<content:encoded><![CDATA[<p>Nice write up. Like your blog. IMHO, Integration testing is just hard to automate, and you have to find the right cost vs benefit to do it. However, the TDD camp &#8211; in general &#8211; are not so big on integration testing, they are mostly concerned about unit testing THEIR code, and usually use mocks to mock away the integration points. This makes tests easier to write and run faster, but unit tests are not as useful as integration tests. Their thing though, is that doing TDD style coding forces you to write well-decoupled code, and the testing is only a part of it &#8211; in other words, testing isn&#8217;t their only goal. But, I think after you get to a certain point of experience, you can probably make the right decision as to what to decouple and what not to.</p>
<p>I don&#8217;t write tests for UIs anymore. I change the design all the time, so what&#8217;s the point? Besides, designing UIs is a visual and interactive process, and there&#8217;s just no way to automatically test whether a UI looks nice or is easy to use.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio Sironi</title>
		<link>http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679/comment-page-1#comment-1456</link>
		<dc:creator>Giorgio Sironi</dc:creator>
		<pubDate>Wed, 05 Aug 2009 14:08:03 +0000</pubDate>
		<guid isPermaLink="false">http://swizec.com/blog/?p=679#comment-1456</guid>
		<description>I&#039;m glad that you see more pros than cons.
2 imho is not a con since code that is hard to test cannot exist, since you must write the test first and then the code under test. That leads to more decoupled code, in this case decoupled from the assumption that the input should came form sys.stdin.</description>
		<content:encoded><![CDATA[<p>I&#8217;m glad that you see more pros than cons.<br />
2 imho is not a con since code that is hard to test cannot exist, since you must write the test first and then the code under test. That leads to more decoupled code, in this case decoupled from the assumption that the input should came form sys.stdin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Loveridge</title>
		<link>http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679/comment-page-1#comment-1455</link>
		<dc:creator>Paul Loveridge</dc:creator>
		<pubDate>Wed, 05 Aug 2009 08:40:53 +0000</pubDate>
		<guid isPermaLink="false">http://swizec.com/blog/?p=679#comment-1455</guid>
		<description>You missed one out :

Unit testing allows teams to have more confidence that their work isn&#039;t breaking someone elses work by accident. (pro)</description>
		<content:encoded><![CDATA[<p>You missed one out :</p>
<p>Unit testing allows teams to have more confidence that their work isn&#8217;t breaking someone elses work by accident. (pro)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Foom</title>
		<link>http://swizec.com/blog/the-ten-pros-and-cons-of-unit-testing/swizec/679/comment-page-1#comment-1451</link>
		<dc:creator>Foom</dc:creator>
		<pubDate>Tue, 04 Aug 2009 12:33:38 +0000</pubDate>
		<guid isPermaLink="false">http://swizec.com/blog/?p=679#comment-1451</guid>
		<description>I think you meant 4 cons and _6_  pros.</description>
		<content:encoded><![CDATA[<p>I think you meant 4 cons and _6_  pros.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
