[erlang-questions] Design strategies for a test suite

[John Haugeland]

I hate having religious wars with myself.

I'm sort of torn on what I believe is the "appropriate" way to handle my new
testing suite, with regards to dealing with export clauses.  I'm not sure
how I feel about being unable to test non-exported functions.

On the one hand, it would be relatively easy to stick a macro into place to
define a stub that would get at the guts of a given module, as well as
provide an export stub for it.  Indeed, this would be a lot less of a
gutwrenching horror option if selective module access was a reality; then I
could explicitly say in my export that the newly exported stub was only
available to the testing rig, and a lot of the bile rushing into my mouth at
the thought of modifying the application's exported function list and
thereby destroying its interface sanctity would subside.

At the same time, there's a lot to be said for only testing what the module
author wants to show to the outside world.  (Granted, I'm a testing
whole-ist, and I want to get at every little detail, but still.)  The
problem is that I worry that this would encourage users of the testing kit
to expose parts of the module that they otherwise wouldn't, or to break down
their module into several smaller modules for the purposes of providing
testable interfaces.

At the same time, I find myself wondering whether such a breakdown wouldn't
be entirely inappropriate.  Indeed, I've already fallen subject to this
effect myself, and it has had some nice side-effects.

Now, in C++, my powers are great enough to use some tremendously ugly macro
magic to get through the access issue.  Unfortunately, that road is foggy at
best when your ninja skills in a given language are secure, and I'm on
pretty shaky footing in Erlang so far.  What I'm hoping is that there's some
wisdom that's already played out here, possibly for other reasons, on which
I can depend.

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?

This would be a whole lot easier to resolve if I could limit which modules
were allowed to call a given function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080516/68ad9cb5/attachment.htm>