[erlang-questions] Design strategies for a test suite
Fri May 16 22:30:23 CEST 2008
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
In general, I do the following at the beginning of the module:
And then at the end of the file I'll add test functions in the same way:
ok = alrules:start(),
ok = test1(),
ok = foo()
That way I can compile testable code with nothing and then production
code with NDEBUG defined.
More information about the erlang-questions