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

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 2 12:04:45 PDT 2015


On 4/2/15 11:44 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Apr 02, 2015 at 11:19:32AM -0700, Jeremy Powers via Digitalmars-d wrote:
>> On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d <
>> digitalmars-d at puremagic.com> wrote:
>>
>>> On 31/03/2015 19:24, Andrei Alexandrescu wrote:
>>>> Probably not; we're looking at two different builds. The build to
>>>> be deployed has no unittest code at all.
>>>
>>> I'm starting to see this differently these days (basically since I
>>> started to use jenkins for everything): A build you haven't unit
>>> tested has implicitly failed. That means the release build that does
>>> not have any unit test bits is not deployable.  Instead, compile as
>>> usual (both debug and release), and run unit tests against both
>>> (e.g. to catch compiler bugs in the optimiser).  Then for
>>> deployment, drop/strip/remove/dont-package the unit test code.
>>>
>>>
>> This.
>>
>> I want to run unit tests as part of the build process, and I want my
>> release build to have unit tests run against it.  If unit tests
>> haven't passed for a build, it's not release ready.  But, I don't want
>> my release build to be bloated with unit test code.
>>
>> Related, unit tests often have dependencies that I _don't_ want as
>> part of my release build.  Mocking frameworks are a good example.
>
> So what do you want the compiler to do? Emit two executables, one
> containing the release, the other containing the unittests? Isn't that
> just a matter of running dmd with/without -unittest?

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.

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.


Andrei


More information about the Digitalmars-d mailing list