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.