On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

...

The way I see it, the notion of having one build with strippable unittests is a nice idea but technically challenging. It's also low impact - today concurrent CPU is cheap so running two concurrent unrelated builds can be made as fast as one.

This works for me. The important part is that the resultant artifacts of the build have had their exact code tested, doesn't really matter if it's the exact same bits or just logical equivalent. As long as it is the _exact_ same, which means test-only dependencies are not part of the being-tested code.

The simple effective step toward improvement is to uniformize the format of assertion errors in unittests and to make it easy with tooling to create unittest and non-unittest builds that are gated by the unittests succeeding.

Nomenclature nitpick: one 'build' with concurrent compile/test steps. Artifacts of build should include a tested library/executable and (uniformly formatted of course) test report.