I believe the discussion started on where the tests should go? Anyway, test driven development is about driving the development of your code based on the tests. In order to get safe-holds and be able to stop at any time, knowing exactly the code base is able/not able to do. As Jon says, this is a topic in which some people tend to get zealous. <div>
<br>I for one do not care whether your tests are on one part of the scale or the other. Really. </div><div>If you create a battery of tests, which for all intents and purposes test and prove that the functional behaviour is sound, and you are happy with that. Great! </div>
<div>Then it's going to be (hopefully) easy for you to change implementation details without carrying too much overhead. Down side - this will tend to give you longer leap-times when moving between Red (tests-failing) and Green (tests-working) states.  </div>
<div><br></div><div>Focusing heavily on the Unit testing perspective, you will have shorter cycles between Red and Green, a perceived higher commit-velocity and most robustness, while also carrying more overhead if you start mutating the implementation details quickly.</div>
<div><br></div><div>Cheers</div><div>/G</div><div><div><br><div class="gmail_quote">On Wed, Jul 6, 2011 at 8:32 PM, Jon Watte <span dir="ltr"><<a href="mailto:jwatte@gmail.com">jwatte@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Actually, test driven development methodology has a very clear separation between these:<div>- acceptance tests / interface tests use only the public, exported interface of a component/system/unit, and tests it in a "clean room" environment.</div>

<div>- unit tests grope around the internals of your unit in a way that nobody on the outside can. It's used to verify implementation details of the unit that may be important to the implementation, but not to anyone on the outside.</div>

<div><br></div><div>There is a little bit of religion in this -- some people tend to feel very strongly that only acceptance tests matter. Personally, I find unit tests to be useful in many cases, especially when growing an implementation using testing in the first place.</div>

<div><br></div><div>For example: You might want to test a gen_server. This gen_server uses a state record that is internal to the module. A unit test, inside the module, can set up a state record, and then call handle_call() directly, making sure that particular implementation details do what they're supposed to. Meanwhile, nobody outside the module should ever call that function (except for the gen_server itself, of course), and any test on the outside should only use the public interface functions.</div>

<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>

<br>
<br><br><div class="gmail_quote">On Tue, Jul 5, 2011 at 10:56 PM, Gianfranco Alongi <span dir="ltr"><<a href="mailto:gianfranco.alongi@gmail.com" target="_blank">gianfranco.alongi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<p>I disagree. <br>
Putting your tests in another module will actually force you to think more of your design, making the application/lib more testable without being necessarily more "open". Another huge win is that you will have a cleaner implementation module. And you will be able to easily mix and match revisions of code and tests. /G</p>



<p></p><blockquote type="cite"><div></div></blockquote></blockquote></div><br><div><br></div></div>
</blockquote></div><br></div></div>