Strategies for resolving cyclic dependencies in static ctors

[Jonathan M Davis]

> Regarding unit tests - I have never been a fan of putting unit test code
> into the modules being tested because:
> * Doing so introduces stacks of unnecessary imports, and bloats the module.
> * Executing the unittests happens during execution rather than during
> the build.
> 
> All unittests (as in the keyword) seem to have going for them is to be
> an aid to documentation.
> 
> What I do instead is put unit tests into separate modules, and use a
> custom build system that compiles, links AND executes the unit test
> modules (when out of date of course). The build fails if a test does not
> pass.
> 
> The separation of the test from the code under test has plenty of
> advantages and no down-side that I can see - assuming you use a build
> system that understands the idea. Some of the advantages are:
> * No code-bloat or unnecessary imports.
> * Much easier to manage inter-module dependencies.
> * The tests can be fairly elaborate, and can serve as well-documented
> examples of how to use the code under test.
> * Since they only execute during the build, and even then only when out
> of date, they can afford to be more complete tests (ie use plenty of cpu
> time)
> * If the code builds, you know all the unit tests pass. No need for a
> special unittest build and manual running of assorted programs to see if
> the tests pass.
> * No need for special builds with -unittest turned on.

Obviously, it wouldn't resolve all of your concerns, but I would point out 
that you can use version(unittest) to enclose stuff that's only supposed to be 
in the unit tests build. And that includes using version(unittest) on imports, 
avoiding having to import stuff which is only needed for unit tests during 
normal builds.

- Jonathan M Davis