Program logic bugs vs input/environmental errors

[via Digitalmars-d]

On Saturday, 18 October 2014 at 05:22:54 UTC, Walter Bright wrote:
> 2. If (1) cannot be done, then write the unittests like:
>
>   {
>     openfile();
>     scope (exit) closefile();
>     scope (failure) assert(0);
>     ... use enforce() instead of assert() ...
>   }
>
> 3. In a script that compiles/runs the unittests, have the 
> script delete any extraneous generated files.

This is bad, it means:

- I risk having my filesystem ruined by running unit-tests 
through the compiler.
- The test environment changes between runs.

Built in unit tests should have no side effects.

Something along these lines would be a better setup:

1. Load a filesystem from a read-only file to a virtual driver.
2. Run a special initializer for unit tests to set up the 
in-memory test environment.
3. Create N forks (N=number of cores):
4. Fork the filesystem/program before running a single unit test.
5. Mount the virtual filesystem (from 1)
6. Run the unit test
7. Collect result from child process and print result.
8. goto 4

But just banning writing to resources would be more suitable. D 
unit tests are only suitable for testing simple library code 
anyway.