[erlang-questions] Design strategies for a test suite

[Paul Fisher]

On Fri, 2008-05-16 at 13:53 -0600, John Haugeland wrote:
> So, presume you're looking at a testing rig meant to have as little
> impact on a given module as possible.  Right now I'm just allowing it
> to be blind to a module's internals, which has allowed me to get my
> testing stuff down to a single line of code in the module to be
> tested.  That said, this limits my ability to test internals unless
> I'm willing to open new holes in my black box for test wires.  And,
> frankly, I'm just not very happy with that option.
> 
> Someone have a better idea?  I mean, if there was a way for me to just
> be horrible and ignore the export inbound call limits, I'd do it in a
> heartbeat, but I don't think that actually exists.
> 
> Should I just gracefully accept export([]) as a limitation?  Should I
> require the use of a macro-granted magical gateway?  Is there another
> option?

In general, I do the following at the beginning of the module:

%% API
-ifdef(NDEBUG).
-export([foo/0]).
-else.
-compile([export_all, debug_info]).
-endif.


And then at the end of the file I'll add test functions in the same way:

-ifndef(NDEBUG).

test() ->
    ok = alrules:start(),
    ok = test1(),
    ok.

test1() ->
    ok = foo()

-endif.

That way I can compile testable code with nothing and then production
code with NDEBUG defined.


-- 
paul