[erlang-questions] How to structure EUnit tests [was: I Hate Unit Testing]

[Dan Milstein]

Love it!  Going to steal this idea immediately.

Totally agree on all your points -- I've always ended up with tests  
within the module, exactly because I don't want to export all my  
private functions. But a) my modules are thus getting a bit unwieldy,  
and b) I have some fears that whatever parse_transform magic is going  
within eunit will cause troubles some day in production.

Thanks for passing this on...
-Dan M


On Jan 29, 2009, at 4:57 AM, Adam Lindberg wrote:

> Thought it might be beneficial to branch this to a side discussion.
>
>
> This is how I use EUnit at the moment. I always use debug compiling  
> and define TEST whenever I want tests compiled into the code.
>
> In myapp/src/foo.erl I put a small header file inclusion:
>
> -ifdef(TEST).
> -include("foo_test.hrl").
> -endif.
>
>
> And myapp/test/foo_tests.hrl looks like this:
>
> -include_lib("eunit/include/eunit.hrl").
>
>
> foo_test_() ->
>    [?_assertEqual(ok, public_function())].
>
> bar_test_() ->
>    [?_assertEqual(ok, private_function())].
>
>
>
> The benefits of this are several
> * Production code and test code are separated
> * Production code can be compiled and distributed without test code
> * Private functions can be tested easily
> * Test code can grow large in a space where it doesn't matter
>
>
> It feels fairly "black box" since the tests are in another file. But  
> I think the most important thing is that I can test private  
> functions with unit tests. It is also easier to see when a module  
> grows too large, since only production code exists in it.
>
>
> Cheers,
> Adam
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>