Doug Way <dway at mailcan.com> wrote:
> Perhaps a preference or option in the TestRunner UI could be added, 
> specifying whether one wants to run all tests in the background vs. 
> foreground.  At least until this issue is fixed, assuming it is fixable.
> 

It is not fixable in general, though surely the Morphic troubles can be
fixed.  Any test might rely on global state that the programmer is
messing with while the tests run.  As one silly example, the programmer
might redefine a class while a test that uses that class is running. 
More serious, a test might access some cache that is being used by a
foreground tool as well -- for example, a SqueakMap or Monticella test
and tool.

I do not think all of Squeak should be made reentrant and thread safe. 
It is way too much trouble.  I single thread as much as possible so that
I do not have to worry about these issues, and background testability is
not enough reason to switch.

One idea for avoiding all of these problems, is to use a separate
*process* instead of a separate thread.  Snapshot Squeak, restart it it
in a new process, and run the tests there.  Then there won't be any
threading issues.  You'd still have, however, issues with external
resources like file-based caches.

I am highly conflicted, by the way, over whether background testing is
really a good idea.  For starters, if your tests take 5 minutes to run,
then it means there is a 5 minute lag before you learn of any bugs.  If
your tests take overnight to run, then you only get one group of bugs
reported per night.  It is nice to have a *fast* test suite, and that's
how I've tried to use SUnit.  Longer tests are... a  different matter. 
They are important, but I do not need them always available at the click
of a button.

Anyway, I hate to say it, but maybe this should in fact be a preference.
 If your tests work okay in a background thread then you are golden.  If
they do not then you can flip the switch.


-Lex