<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">...<br>
</blockquote>
<br></div></div>
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.<br>
<br></blockquote><div><div><br></div><div>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.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br><br></blockquote><div><br></div><div>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.</div></div></div></div>