<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>Toxic Elephant : Tag mocking, everything about mocking</title>
    <link>http://www.matijs.net/blog/tag/mocking.rss</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>Don't bury it in your back yard!</description>
    <item>
      <title>I'm not a Mockist</title>
      <description>&lt;p&gt;Let&amp;#8217;s talk about mocking.&lt;/p&gt;


	&lt;p&gt;It apparently is the hot new thing in &lt;a href="http://rubyonrails.org"&gt;Rails&lt;/a&gt;
land. And like earlier &lt;a href="http://www.matijs.net/blog/articles/2006/10/18/how-to-write-software"&gt;silver
bullets&lt;/a&gt;,
it&amp;#8217;s becoming a religion: Acolytes would rather write ten lines to set up a
mock object than one to instantiate an actual one.&lt;/p&gt;


	&lt;p&gt;Honestly, I have tried to understand the benefits of mocking, but I just don&amp;#8217;t see
them&lt;sup&gt;&lt;a href="#fn1"&gt;1&lt;/a&gt;&lt;/sup&gt;. Then I thought I would have to write a long article about how
mocking is flawed, and would you people please all see sense already.
Luckily, Martin Fowler did it for me, and with a lot more objectivity. Go
read his &amp;#8216;&lt;a href="http://martinfowler.com/articles/mocksArentStubs.html"&gt;Mocks Aren&amp;#8217;t
Stubs&lt;/a&gt;&amp;#8217;. In addition
to explaining the difference between Mocks and Stubs (a difference often
overlooked by the religious), he explains why you might not want to use
what he calls &amp;#8220;mockist testing&amp;#8221;.&lt;/p&gt;


	&lt;p&gt;So, in the spirit of religious tolerance, I can now say: I&amp;#8217;m not a Mockist.&lt;/p&gt;


	&lt;p&gt;My particular reasons?&lt;/p&gt;


	&lt;ul&gt;
	&lt;li&gt;Mockist testing is not &lt;span class="caps"&gt;DRY&lt;/span&gt;: Each class&amp;#8217; behavior is now defined in its
  code, its unit tests, and each time it is mocked.&lt;/li&gt;
		&lt;li&gt;Mockist testing tests a particular implementation of behavior, making
  refactoring harder.&lt;/li&gt;
		&lt;li&gt;Mockist testing makes writing your tests more work, inviting you not to test.&lt;/li&gt;
	&lt;/ul&gt;


	&lt;p&gt;Next time you find yourself complaining that setting up your mock objects
is such a lot of work, ask yourself: &amp;#8220;Am I a Mockist?&amp;#8221;. Maybe you&amp;#8217;re not.&lt;/p&gt;


	&lt;p id="fn1"&gt;&lt;sup&gt;1&lt;/sup&gt; Well, one minor benifit I &lt;em&gt;can&lt;/em&gt; see that you can start writing and testing your views before having written your models. I never seem to want to do that anyway, though.&lt;/p&gt;</description>
      <pubDate>Sun, 04 Nov 2007 13:56:00 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:04da932f-1828-4516-90ee-04dc6c16d3cf</guid>
      <author>blog@matijs.net (matijs)</author>
      <comments>http://www.matijs.net/blog/2007/11/04/im-not-a-mockist#comments</comments>
      <category>software</category>
      <category>rails</category>
      <category>mocking</category>
      <category>software</category>
      <trackback:ping>http://www.matijs.net/blog/trackbacks?article_id=im-not-a-mockist&amp;day=04&amp;month=11&amp;year=2007</trackback:ping>
      <link>http://www.matijs.net/blog/2007/11/04/im-not-a-mockist</link>
    </item>
  </channel>
</rss>
