[erlang-questions] Unit testing code - whence?

[Gianfranco Alongi]

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.

I for one do not care whether your tests are on one part of the scale or the
other. Really.
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!
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.

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.

Cheers
/G

On Wed, Jul 6, 2011 at 8:32 PM, Jon Watte <jwatte@REDACTED> wrote:

> Actually, test driven development methodology has a very clear separation
> between these:
> - acceptance tests / interface tests use only the public, exported
> interface of a component/system/unit, and tests it in a "clean room"
> environment.
> - 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.
>
> 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.
>
> 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.
>
> Sincerely,
>
> jw
>
>
> --
> 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.
>
>
>
> On Tue, Jul 5, 2011 at 10:56 PM, Gianfranco Alongi <
> gianfranco.alongi@REDACTED> wrote:
>
>> I disagree.
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110706/fa84eb7d/attachment.htm>