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

[Dicebot via Digitalmars-d]

On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu 
wrote:
> On 3/30/15 3:30 PM, Dicebot wrote:
>> tl: dr: please, no
>>
>> We have put quite some effort into fighting default DMD 
>> behaviour of
>> -unittest simply adding to main function and not replacing it. 
>> Initially
>> many applications did run tests on startup because DMD 
>> suggested it is a
>> good idea - some rather bad practical experience has shown 
>> this was a
>> rather bad suggestion. Accidental tests that start doing I/O on
>> productions servers, considerably increased restart times for 
>> services -
>> that kind of issues.
>
> 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.

Ok, pardon me for misunderstanding :) I got confused by "you 
don't want to run application that isn't tested" part.

>> And if you suggest to build both test and normal build as part 
>> of single
>> compiler call (building test version silently in the 
>> background) this is
>> also very confusing addition hardly worth its gain.
>
> Making the format of unittest failures better would take us a 
> long way. Then we can script builds so the unittest and release 
> build are created concurrently.

If it is only format that matters you an always change it via 
custom test runner. For example, we do have a test runner that 
generates JUnit-compatible XML output for Jenkins - and that was 
possible to do with plain `unittest` blocks even with D1 :)

Main problem with changing default formatting is that it is 
pretty hard to choose one that is 100% right. Current one is at 
least simple and predictable being just an exception printout.