I hate having religious wars with myself.<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br><br>
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.<br>
<br>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.<br>
<br>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.<br><br>Should I just gracefully accept export([]) as a limitation?  Should I require the use of a macro-granted magical gateway?  Is there another option?<br>
<br>This would be a whole lot easier to resolve if I could limit which modules were allowed to call a given function.<br>