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

[Johannes Totz via Digitalmars-d]

On 31/03/2015 19:24, Andrei Alexandrescu wrote:
> On 3/31/15 9:21 AM, qznc wrote:
>> On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu wrote:
>>> Violent agreement here. I was just saying unittests should be part of
>>> the build process, not the run process. Running unittests and then the
>>> app is a bad idea.
>>
>> Sounds like a good idea to me.
>>
>> Then -unittest should be enabled by default?
> 
> 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.

> 
>> Implementationwise it sounds like you want another entry point apart
>> from main, e.g. "main_unittest". Then the build process is
>> compile-link-unittest. Afterwards the run process is the usual main call.
>>
>> It makes binaries bigger though. Maybe unittest-specific code can be
>> placed in a special segment, which can be removed during deployment?
> 
> Interesting. Or could be a dynamically-loaded library. But... crawl
> before we walk.
> 
> 
> Andrei
>