http://code.dlang.org/packages/unit-threaded

Other than some bug fixes, the big news here is a version of the library that compiles a _lot_ faster: just add `"versions": ["unitThreadedLight"]` in `dub.json` or the equivalent for however you're building your project. If using dub, I suggest having two configurations: one for the regular unit-threaded build and another specifying `unitThreadedLight`.

So what's the catch? Pretty much that the features all go away. But: I realised that for the most part what one wants to do is just run all tests and know they all passed. All the advanced reporting, test naming, test selection etc. is only really useful when things _don't_ work. So I figured a trade-off would be to have a light mode that doesn't use compile-time reflection nor generates a bunch of code for each type to print out its value. Just use the default unittest runner and import the smallest possible number of modules. I even used printf instead of writeln to write out "Ok: All tests passed" because there was a measureble difference in compilation speed.

But what about all the custom `should` assertions? I replicated _all_ of them in the light mode by doing the bare minimum possible. Other things like mocking or property-based testing are hidden behind templates that only import the relevant modules if needed. I tested the influence on compile times between using `shouldEqual` and `assert`: it was small enough to not matter with the new version.

The result is a compile-time of about 0.2s on my machine (using dub adds another 0.2s on top of that or more if actually checking for dependencies) for a toy project with 200 unittest blocks. YMMV depending on how many advanced features you use. For instance, things like `@HiddenTest` and `@ShouldFail` will definitely not work. But, those could always be versioned away by checking for `unitThreadedLight`. If you compare this with the ~0.35s in compile time that it costs to write `import unit_threaded;` in the full-featured mode... never mind the ~1.1s to compile that toy project with the standard version.

I think the way I'll use this myself is to run the fast version by default when developing and switching to the slow version for debugging if it fails, automating this in a script like so:

# if the fast version fails run the slow one
dub run -q --nodeps -c ut || dub test -q --nodeps

This assumes there's a "ut" dub configuration specifying `unitThreadedLight` and `-unittest` and a "unittest" configuration that runs "normal" unit-threaded.

I haven't thoroughly tested the new mode though, so expect bugs. Good thing there's a fallback.

Atila