<?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 Art of Unit Testing Book Review</title>
	<atom:link href="http://www.stum.de/2009/09/02/the-art-of-unit-testing-book-review/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.stum.de/2009/09/02/the-art-of-unit-testing-book-review/</link>
	<description>Random thoughts of neat disorder</description>
	<lastBuildDate>Wed, 11 Jan 2012 04:38:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Wes</title>
		<link>http://www.stum.de/2009/09/02/the-art-of-unit-testing-book-review/comment-page-1/#comment-9385</link>
		<dc:creator>Wes</dc:creator>
		<pubDate>Wed, 02 Sep 2009 18:49:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.stum.de/?p=550#comment-9385</guid>
		<description>I should probably write my own review of this book, but to quickly point out Chapter 7 as being the most profound chapter in my mind as it presents many Best Practices that can make the difference between good and bad tests.  This fundamentally changed how I look at unit testing.  Thanks Roy!</description>
		<content:encoded><![CDATA[<p>I should probably write my own review of this book, but to quickly point out Chapter 7 as being the most profound chapter in my mind as it presents many Best Practices that can make the difference between good and bad tests.  This fundamentally changed how I look at unit testing.  Thanks Roy!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wes</title>
		<link>http://www.stum.de/2009/09/02/the-art-of-unit-testing-book-review/comment-page-1/#comment-9384</link>
		<dc:creator>Wes</dc:creator>
		<pubDate>Wed, 02 Sep 2009 18:46:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.stum.de/?p=550#comment-9384</guid>
		<description>I think the reason that you don&#039;t see and won&#039;t see a lot of coverage of unit testing a view layer is that they are often very expensive to test and really difficult to isolate as units.  Views often require integration and/or systems testing.  So I&#039;m not sure that should be covered in a book on unit testing.  Spinning up the .net framework to test a view is no longer testing a unit as the dependencies on the underlying framework haven&#039;t been isolated.  The same can be said for WPF, WinForms, WCF or any other framework that cannot be isolated and is required around the edges of your application.

Striving to make views very simple through MV* patterns often removes a lot of the code from the view and leaves less room for failure.  Theoretically, a good view only has wire up mechanisms to extract/present data and to forward commands.  Beyond that you can look to frameworks that do integration testing to provide you with the tools to test views.  I would also stress to be careful of the extent of testing you do here as it can become very expensive and result in brittle tests, especially if they are long running and often only are tested in a CI environment, say on a daily basis (highly likely chance people will break tests if they aren&#039;t constantly running them).  A lot of people encourage simple smoke screen tests as the best ROI for testing the view layer.  Thoughts?</description>
		<content:encoded><![CDATA[<p>I think the reason that you don't see and won't see a lot of coverage of unit testing a view layer is that they are often very expensive to test and really difficult to isolate as units.  Views often require integration and/or systems testing.  So I'm not sure that should be covered in a book on unit testing.  Spinning up the .net framework to test a view is no longer testing a unit as the dependencies on the underlying framework haven't been isolated.  The same can be said for WPF, WinForms, WCF or any other framework that cannot be isolated and is required around the edges of your application.</p>
<p>Striving to make views very simple through MV* patterns often removes a lot of the code from the view and leaves less room for failure.  Theoretically, a good view only has wire up mechanisms to extract/present data and to forward commands.  Beyond that you can look to frameworks that do integration testing to provide you with the tools to test views.  I would also stress to be careful of the extent of testing you do here as it can become very expensive and result in brittle tests, especially if they are long running and often only are tested in a CI environment, say on a daily basis (highly likely chance people will break tests if they aren't constantly running them).  A lot of people encourage simple smoke screen tests as the best ROI for testing the view layer.  Thoughts?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jnystrom</title>
		<link>http://www.stum.de/2009/09/02/the-art-of-unit-testing-book-review/comment-page-1/#comment-9381</link>
		<dc:creator>jnystrom</dc:creator>
		<pubDate>Wed, 02 Sep 2009 18:21:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.stum.de/?p=550#comment-9381</guid>
		<description>I bought the book after hearing him on Hanselman&#039;s podcast but have put off reading it.  This review motivates me to devote some time to reading this book...finally.</description>
		<content:encoded><![CDATA[<p>I bought the book after hearing him on Hanselman's podcast but have put off reading it.  This review motivates me to devote some time to reading this book...finally.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

