Should unittests run as logical part of compilation?

[Andrei Alexandrescu]

On 1/26/14 4:58 AM, Idan Arye wrote:
> I don't think unit tests should be run on *each* build - if I'm
> fidgeting with a specific piece of my code, and building&running it
> after each change, I don't want to waste time running the unittests of
> the entire project.

Hah, interesting. So unittests of one module should run again iff there 
were changes in that module or other modules that that depends on.

> How about keeping the old behavior of `-unittest` for backward
> compatibility, and having a new syntax - `-unittest=filename`, where
> "filename" is the name of the unittests executable.

Sounds interesting.

> That way both the
> unittest and the regular executables will be created at the same time -
> which will speed things up, as most of the compilation work can be
> shared between those two builds - and have different file names, so the
> build system - which will make configuring the build system more
> straightforward.

Yeppers. One other thought I had was to define a special flag e.g. 
--4c5ad7908c2aa1b3de32ea25968cdf49 that says "just run unittests".

> If we make the unittest a separate executable, there won't be a `main`
> function waiting for command line arguments, so we can use the command
> line arguments for the unittests. We can have flags for only running
> tests of specific packages, or for running the tests under certain
> restrictions etc.

There we go :o).


Andrei