Should unittests run as logical part of compilation?

[deadalnix]

On Saturday, 25 January 2014 at 22:55:33 UTC, Andrei Alexandrescu 
wrote:
> There's this simple realization that unittests could (should?) 
> be considered an intrinsic part of the build process. In order 
> for an executable to be worth running, it should pass the 
> regular semantic checks and also the unittests, which in a 
> sense are extended semantic checks that fall outside the 
> traditional charter of the compiler.
>
> In that view, asserts inside unittests should fail with the 
> same message format as regular compilation errors, i.e.
>
> ./modulename.d(103): Unittest failed: user-defined message
>
> Stack traces and other artifacts printed by failing asserts 
> should come after, indented. An IDE user should run unittest 
> with the usual "build" command and be able to click on the 
> unittest failures just the same as build errors.
>
> In particular, this view of unittests declares our current 
> stance on running unittests ("run unittests just before 
> main()") as meaningless. Indeed that has bothered me for quite 
> a while - unittests are part of the build/acceptance, not part 
> of every run. To wit, this is a growing idiom in D programs:
>
> version(unittest) void main() {}
> else void main()
> {
>     ...
> }
>
> What do you think? Logistically it shouldn't be too hard to 
> arrange things to cater to this approach.
>
>
> Andrei

+1, unittest passed as command line argument to dmd should run 
unittests as compilation step and main should remain untouched.