Should unittests run as logical part of compilation?

[Gary Willoughby]

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

I don't fully understand this. Are you proposing to disconnect 
running unittest and evoking main? So unittests can be compiled 
and run without actually running the program?

If this is the case then yes it would be nice to be able to do 
this but i would also recommend keeping the current behaviour of 
invoking main after the unittests have run, purely because 
developers (myself included) like to run the application often in 
debug/unittest mode during development.