<?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"
	>
<channel>
	<title>Comments on: To Mock Or Not To Mock</title>
	<atom:link href="http://www.blizzo.com/to-mock-or-not-to-mock/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.blizzo.com/to-mock-or-not-to-mock/</link>
	<description>Randomness for you since 1976</description>
	<pubDate>Wed, 07 Jan 2009 03:37:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Peter Williams</title>
		<link>http://www.blizzo.com/to-mock-or-not-to-mock/#comment-238</link>
		<dc:creator>Peter Williams</dc:creator>
		<pubDate>Fri, 15 Jun 2007 17:37:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.blizzo.com/?p=58#comment-238</guid>
		<description>&lt;strong&gt;Mocking...&lt;/strong&gt;

Mr Whitney recently posted an article in which he described mock objects as &#8220;bug aggregators&#8221;.
I once held a similar point of view.
Back then my belief was that test doubles (mock, stub, etc)
should only be used when real
objects would not ...</description>
		<content:encoded><![CDATA[<p><strong>Mocking&#8230;</strong></p>
<p>Mr Whitney recently posted an article in which he described mock objects as &#8220;bug aggregators&#8221;.<br />
I once held a similar point of view.<br />
Back then my belief was that test doubles (mock, stub, etc)<br />
should only be used when real<br />
objects would not &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Catherine</title>
		<link>http://www.blizzo.com/to-mock-or-not-to-mock/#comment-239</link>
		<dc:creator>Catherine</dc:creator>
		<pubDate>Tue, 12 Jun 2007 05:23:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.blizzo.com/?p=58#comment-239</guid>
		<description>hallelujah on separating hibernate from the database

I had worked very happily not knowing this beast. Once I met it, I can't say we're friends. But then again, I think people - namely your friendly database architect - should control the schema, not what make hibernate the happiest.

Not that that was Morgan's point at all, I at least know that much.</description>
		<content:encoded><![CDATA[<p>hallelujah on separating hibernate from the database</p>
<p>I had worked very happily not knowing this beast. Once I met it, I can&#8217;t say we&#8217;re friends. But then again, I think people - namely your friendly database architect - should control the schema, not what make hibernate the happiest.</p>
<p>Not that that was Morgan&#8217;s point at all, I at least know that much.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason E. Rist</title>
		<link>http://www.blizzo.com/to-mock-or-not-to-mock/#comment-240</link>
		<dc:creator>Jason E. Rist</dc:creator>
		<pubDate>Thu, 07 Jun 2007 17:35:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.blizzo.com/?p=58#comment-240</guid>
		<description>I've encountered this recently at work as well.  From my experience Mocks do have their place, but they seem to be in what you mentioned - simulating lookup data from a database.  Until we get a chance to rewrite our code to use HSQL and then separate Hibernate from the database, we have to use Mocks for our DAOs.  (Side-notes: we're writing the tests for code that is already in place and haven't yet gotten to the Mocks for the DAOs.  I'm sure it will be painful soon!)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve encountered this recently at work as well.  From my experience Mocks do have their place, but they seem to be in what you mentioned - simulating lookup data from a database.  Until we get a chance to rewrite our code to use HSQL and then separate Hibernate from the database, we have to use Mocks for our DAOs.  (Side-notes: we&#8217;re writing the tests for code that is already in place and haven&#8217;t yet gotten to the Mocks for the DAOs.  I&#8217;m sure it will be painful soon!)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
