An Interesting approach. I'm going to have to try this later.<br><br><div class="gmail_quote">On Tue, Jun 3, 2008 at 7:14 AM, Dominic Williams <<a href="mailto:erlang-dated-1212927270.714ba1@dominicwilliams.net">erlang-dated-1212927270.714ba1@dominicwilliams.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Jeremy,<br>
<div class="Ih2E3d"><br>
> what is the typical way to handle the case where your module<br>
> uses ibrowse say.<br>
><br>
> is the best practice in testing just to not mock ibrowse?  or<br>
> do you typically just isolate the ibrowse calls in a small<br>
> untested function and test everything else as normal?  or is<br>
> there some other trick I dont know about yet?<br>
<br>
</div>This is one of the reasons that I do not subscribe to the<br>
"traditional" Erlang practise of writing interface modules that<br>
hide message passing behind function calls. I like to expose the<br>
message passing and have the message protocol /be/ the official<br>
interface. Testing and mocking become very much easier.<br>
<br>
However, when faced with existing applications that use the<br>
interface module approach (such as, in your case, ibrowse) , I<br>
resort to one of the following to perform mocking:<br>
<br>
- define my own set of messages (usually a small subset of the<br>
  applications full functionality) and introduce a bridge process<br>
<br>
- invert the dependency: avoid side-effects and don't call out to<br>
  ibrowse directly from the module that needs to be tested: have<br>
  it return lists of "ibrowse command" terms, and let the caller<br>
  pass these on to a dumb (untested) module that makes the actual<br>
  ibrowse calls given these terms<br>
<br>
- create higher-order functions: always pass into the functions<br>
  of the module you want to test (that makes the ibrowse calls)<br>
  the functions it should use to make the calls. When there are<br>
  too many functions to make this practical, either pass in a<br>
  module, or pass in a single function whose first argument could<br>
  be the ibrowse function name...<br>
<br>
- use parameterised modules, with the name of the module to be<br>
  used to make ibrowse calls being a parameter.<br>
<br>
I am driven to adopt such approaches in order to achieve good<br>
testability, but in my experience they turn out to be good<br>
designs in themselves, with more flexibility and modularity.<br>
<div><div></div><div class="Wj3C7c"><br>
Regards,<br>
<br>
Dominic Williams<br>
<a href="http://dominicwilliams.net" target="_blank">http://dominicwilliams.net</a><br>
<br>
----<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jeremy Wall<br><a href="http://jeremy.marzhillstudios.com">http://jeremy.marzhillstudios.com</a><br><a href="mailto:Jeremy@marzhillstudios.com">Jeremy@marzhillstudios.com</a>