Should unittests run as logical part of compilation?

[Andrei Alexandrescu]

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