unittests are really part of the build, not a special run

Jeremy Powers via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 2 14:41:45 PDT 2015


On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150402/fb124367/attachment-0001.html>


More information about the Digitalmars-d mailing list