<?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: Mocks Are A Sometimes Food</title>
	<atom:link href="http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/</link>
	<description>Living in a state of accord.</description>
	<pubDate>Fri, 09 Jan 2009 21:40:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Pat</title>
		<link>http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/comment-page-1/#comment-32003</link>
		<dc:creator>Pat</dc:creator>
		<pubDate>Wed, 13 Sep 2006 06:20:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/#comment-32003</guid>
		<description>It's very easy for mocks to get out of hand. I like the following paper &lt;a href="http://www.jmock.org/oopsla2004.pdf" rel="nofollow"&gt;(hope this link works)&lt;/a&gt; that describes in better detail how to get the most out of mocks. I prefer the use of JMock myself, but I see that EasyMock is moving to the same sort of Domain Specific Language patterns of expectations. 

On a personal note, I reserve mocks for where I understand the boundary to be relatively unchanging, or I expect it to be stable going forward. I dislike using it for areas where I don't understand the real interactions (I'd prefer to stub or get more integration tests going) because at least it will be more realistic. I definitely don't think we should ever be coming domain objects.

Hope this helps.</description>
		<content:encoded><![CDATA[<p>It&#8217;s very easy for mocks to get out of hand. I like the following paper <a href="http://www.jmock.org/oopsla2004.pdf" rel="nofollow">(hope this link works)</a> that describes in better detail how to get the most out of mocks. I prefer the use of JMock myself, but I see that EasyMock is moving to the same sort of Domain Specific Language patterns of expectations. </p>
<p>On a personal note, I reserve mocks for where I understand the boundary to be relatively unchanging, or I expect it to be stable going forward. I dislike using it for areas where I don&#8217;t understand the real interactions (I&#8217;d prefer to stub or get more integration tests going) because at least it will be more realistic. I definitely don&#8217;t think we should ever be coming domain objects.</p>
<p>Hope this helps.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adrian Sutton</title>
		<link>http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/comment-page-1/#comment-31971</link>
		<dc:creator>Adrian Sutton</dc:creator>
		<pubDate>Tue, 12 Sep 2006 22:30:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/#comment-31971</guid>
		<description>Hi Tim,
We actually use EasyMock for nearly all of our mocks and we use the class extension to avoid having to create interfaces for absolutely everything - on the whole it's fairly efficient to write the tests. The problem is that every time you create a new mock instance, it defines and loads a new class for that mock so you very quickly run out of permgen space. We've since developed a simple wrapper that reuses mocks which sped up our tests a fair bit and solved the permgen space problem.

We've also developed a couple of custom, hand-crafted mock classes for some key datastructure type classes - the document itself and the elements that make it up. The custom mocks are far more flexible than EasyMock for this particular case and it's made testing easier and avoided the problem of our code being forced to stay within the bounds of what the EasyMock makes easy for us.</description>
		<content:encoded><![CDATA[<p>Hi Tim,<br />
We actually use EasyMock for nearly all of our mocks and we use the class extension to avoid having to create interfaces for absolutely everything - on the whole it&#8217;s fairly efficient to write the tests. The problem is that every time you create a new mock instance, it defines and loads a new class for that mock so you very quickly run out of permgen space. We&#8217;ve since developed a simple wrapper that reuses mocks which sped up our tests a fair bit and solved the permgen space problem.</p>
<p>We&#8217;ve also developed a couple of custom, hand-crafted mock classes for some key datastructure type classes - the document itself and the elements that make it up. The custom mocks are far more flexible than EasyMock for this particular case and it&#8217;s made testing easier and avoided the problem of our code being forced to stay within the bounds of what the EasyMock makes easy for us.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim O'Brien</title>
		<link>http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/comment-page-1/#comment-31944</link>
		<dc:creator>Tim O'Brien</dc:creator>
		<pubDate>Tue, 12 Sep 2006 16:09:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2006/09/11/mocks-are-a-sometimes-food/#comment-31944</guid>
		<description>I worked at an organization that went Mock crazy.  Every class (and I mean every class) was an interface with both a concrete implementation and a mock implementation.   We had good test coverage, but I couldn't help but get the sense that creating mock classes was something of a distraction from "The Prime Directive" (addressing real requirements).  And, that's about the sense I get of unit testing in general, TDD is a nice idea, but to really commit to it, you'll tend to focus on testing before you've even fleshed out what a system needs to look like.  I know it is contrary, but I don't think to think that tests can only come first in the most mature system.  there's a fair amount of tinkering necessary before you can really settle on the right interface (and by interface, I don't necessarily mean "Interface")

Unfortunately, "Tests are a Sometimes Food", and that isn't by choice, it is by necessity. 

BTW, my solution to the mock issue (too many classes) is to use EasyMock - instead of creating a Mock class, you create something of a dynamic proxy object and then you train it.  I've found that it is a great way to achieve Mock objects without having to go to the trouble of creating Mock classes.

And, the PermGen space - I think it is only 64M by default?  (might be 256M, I forget).  Seems to me that the default is too low these days, I've run up against it recently in a web application with too many JSPs.</description>
		<content:encoded><![CDATA[<p>I worked at an organization that went Mock crazy.  Every class (and I mean every class) was an interface with both a concrete implementation and a mock implementation.   We had good test coverage, but I couldn&#8217;t help but get the sense that creating mock classes was something of a distraction from &#8220;The Prime Directive&#8221; (addressing real requirements).  And, that&#8217;s about the sense I get of unit testing in general, TDD is a nice idea, but to really commit to it, you&#8217;ll tend to focus on testing before you&#8217;ve even fleshed out what a system needs to look like.  I know it is contrary, but I don&#8217;t think to think that tests can only come first in the most mature system.  there&#8217;s a fair amount of tinkering necessary before you can really settle on the right interface (and by interface, I don&#8217;t necessarily mean &#8220;Interface&#8221;)</p>
<p>Unfortunately, &#8220;Tests are a Sometimes Food&#8221;, and that isn&#8217;t by choice, it is by necessity. </p>
<p>BTW, my solution to the mock issue (too many classes) is to use EasyMock - instead of creating a Mock class, you create something of a dynamic proxy object and then you train it.  I&#8217;ve found that it is a great way to achieve Mock objects without having to go to the trouble of creating Mock classes.</p>
<p>And, the PermGen space - I think it is only 64M by default?  (might be 256M, I forget).  Seems to me that the default is too low these days, I&#8217;ve run up against it recently in a web application with too many JSPs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
