[plt-scheme] Exposing non-exported module variable bindings.

Lo, on Wednesday, December 17, Dor Kleiman did write:

> Open DrScheme; open the file that contains the module you would like to
> test. Choose the language 'module'. Then, click Execute. The module that
> you are testing will actually be the top run-level, and the REPL would
> be able to use its unexposed variables.

Yes, I know that.  But I don't want to put my test cases in the module
itself, for a variety of reasons:

  1) It clutters up the code unnecessarily.
 
  2) Requiring the schemeunit modules causes executions to take
     dramatically more time; I don't want to pay this penalty unless I'm
     actually testing the code.

  3) Since, last time I checked, the schemeunit gui was still broken
     when used with CVS versions of DrScheme, I've fallen back on the
     text interface.  With this interface, I find it convenient to
     define the test cases in such a way that they will be run
     automatically when I hit Execute.  If I do that, then I definitely
     don't want to put the test cases in the module itself; they'll be
     run every time I load the module.

There are others.  Suffice to say that, since the abstraction boundary
has a hole in it anyway, I'm perfectly willing to use it to make testing
easier.

I haven't thought about the problem in any detail or looked at existing
research in this specific area, but my suspicion is that closing down
all such holes results in a language that is theoretically very clean
but so inflexible as to be impractical.

I may, of course, be wrong; there may be ways to define firm abstraction
barriers in such a way that they don't interfere with testability.  Once
I get through with finals, I may look into this problem a bit more
closely.

Richard