<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
  <title>opensoul.org - How to test dependencies on external services? Comments</title>
  <id>tag:opensoul.org,2008:/2007/4/25/how-to-test-dependencies-on-external-services/comments</id>
  <generator uri="http://mephistoblog.com" version="0.7.3">Mephisto Noh-Varr</generator>
  <link href="http://opensoul.org/2007/4/25/how-to-test-dependencies-on-external-services/comments.xml" rel="self" type="application/atom+xml"/>
  <link href="/2007/4/25/how-to-test-dependencies-on-external-services" rel="alternate" type="text/html"/>
  <updated>2007-04-25T22:14:15Z</updated>
  <entry xml:base="http://opensoul.org/">
    <author>
      <name>Floehopper</name>
    </author>
    <id>tag:opensoul.org,2007-04-25:2736:2740</id>
    <published>2007-04-25T22:14:15Z</published>
    <updated>2007-04-25T22:14:15Z</updated>
    <category term="work"/>
    <link href="http://opensoul.org/2007/4/25/how-to-test-dependencies-on-external-services" rel="alternate" type="text/html"/>
    <title>Comment on 'How to test dependencies on external services?' by Floehopper</title>
<content type="html">&lt;p&gt;At first I thought it would help you to read the &#8220;Don&#8217;t mock third-party libraries&#8221; section of &lt;a href=&quot;http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html&quot;&gt;this article&lt;/a&gt;. But then I realised Tinder is actually meant to be the &#8220;adapter layer&#8221; that Steve Freeman talks about.&lt;/p&gt;


	&lt;p&gt;So then I thought you might be better off doing something like what&#8217;s described in &lt;a href=&quot;http://blog.tammersaleh.com/articles/2007/02/13/mocking-a-network-resource-with-camping&quot;&gt;this article&lt;/a&gt;&lt;/p&gt;


	&lt;p&gt;I hope that&#8217;s of some help.&lt;/p&gt;</content>  </entry>
  <entry xml:base="http://opensoul.org/">
    <author>
      <name>Brandon</name>
    </author>
    <id>tag:opensoul.org,2007-04-25:2736:2739</id>
    <published>2007-04-25T21:24:54Z</published>
    <updated>2007-04-25T21:24:54Z</updated>
    <category term="work"/>
    <link href="http://opensoul.org/2007/4/25/how-to-test-dependencies-on-external-services" rel="alternate" type="text/html"/>
    <title>Comment on 'How to test dependencies on external services?' by Brandon</title>
<content type="html">&lt;p&gt;Scott: Excellent idea.&lt;/p&gt;


	&lt;p&gt;Zach, mocking, stubbing, and dependency injection work great when you&#8217;re testing code that uses other code that is the external dependency, but when your code &lt;code&gt;IS&lt;/code&gt; the dependency, it doesn&#8217;t help much.  Somehow I need to prove that my code does what it&#8217;s supposed to when interacting with the external service.&lt;/p&gt;</content>  </entry>
  <entry xml:base="http://opensoul.org/">
    <author>
      <name>Zach Moazeni</name>
    </author>
    <id>tag:opensoul.org,2007-04-25:2736:2738</id>
    <published>2007-04-25T20:59:43Z</published>
    <updated>2007-04-25T20:59:43Z</updated>
    <category term="work"/>
    <link href="http://opensoul.org/2007/4/25/how-to-test-dependencies-on-external-services" rel="alternate" type="text/html"/>
    <title>Comment on 'How to test dependencies on external services?' by Zach Moazeni</title>
<content type="html">&lt;p&gt;Using Mock Objects will helps me tremendously. Some people view it as &#8220;peeking into the guts&#8221; however, I strongly believe that you are asserting behavior. When you mock out the external dependencies you are allowed to test the object in isolation.&lt;/p&gt;


	&lt;p&gt;You become more intentional on what you want to test as you can easily simulate behaviors the external dependencies should exhibit. Just as important, you can assert your code&#8217;s interaction with the dependencies (asserting the methods / parameters used).&lt;/p&gt;


	&lt;p&gt;I&#8217;m not sure about the underlying code for Tinder, but seeing the snipbit given I&#8217;m going to assume that objects are instantiated within Tinder::Campfire. This becomes a thorn in mock testing since it&#8217;s not as easy to inject the dependencies. Two solutions that I generally take are a) Use some type of Dependency Injection like &lt;a href=&quot;http://rubyforge.org/projects/needle/&quot;&gt;Needle&lt;/a&gt; or b) use stubbing capabilities to whichever mock library you&#8217;re using, for example both &lt;a href=&quot;http://mocha.rubyforge.org/&quot;&gt;Mocha&lt;/a&gt; and &lt;a href=&quot;http://onestepback.org/software/flexmock/&quot;&gt;Flexmock&lt;/a&gt; provide these. Just be wary of overuse of stubbing.&lt;/p&gt;</content>  </entry>
  <entry xml:base="http://opensoul.org/">
    <author>
      <name>Scott Raymond</name>
    </author>
    <id>tag:opensoul.org,2007-04-25:2736:2737</id>
    <published>2007-04-25T19:52:07Z</published>
    <updated>2007-04-25T19:52:07Z</updated>
    <category term="work"/>
    <link href="http://opensoul.org/2007/4/25/how-to-test-dependencies-on-external-services" rel="alternate" type="text/html"/>
    <title>Comment on 'How to test dependencies on external services?' by Scott Raymond</title>
<content type="html">&lt;p&gt;My preferred method is to cache the service&#8217;s responses locally, and then flush the cache periodically in order to detect breakage on the service&#8217;s end. Ideally, I&#8217;d run a CI server that would flush the cache and re-run the tests with every checkin. That way, my local tests could always used the cached responses (keeping them speedy, and able to run off-line), but I&#8217;d still get quick notification if the remote service changed.&lt;/p&gt;</content>  </entry>
</feed>
