Should unittests run as logical part of compilation?

[Mike]

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.
> [...]
> What do you think? Logistically it shouldn't be too hard to 
> arrange things to cater to this approach.
>

How does this work for those who build on one machine and test on 
another?  I'm currently building on a Linux host, and deploying 
to a bare-metal ARM Cortex-M processor.  Also, with limited 
amounts of flash, I may only have enough room for unit tests or 
my program, but not both.  (Just so you know, I don't actually 
use the unit test feature yet, but I intend to)

This seems more like a workflow feature rather than a build 
feature.  But integration into the toolchain could be pretty cool 
(like you said, clicking on a messages in the output window, and 
zooming right to the point of failure).

It seems to me that having an additional tool in the tool chain 
(the unit tester) along with the compiler, linker, debugger, 
etc.. that could be initiated by the build process, is the way to 
go.  If compiling unit tests, the build process could generate a 
unit test executable, run the unit test executable, and, assuming 
all tests pass, then generate the production executable.  I think 
such a tool could scale to my platform, somehow, I suppose.

Mike