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.

Reply via email to