unittests are really part of the build, not a special run

["Nordlöw" via Digitalmars-d]

On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu 
wrote:
> In brief: I'd like to transition to a model in which 
> unittesting is organically part of the build. After all, you 
> wouldn't want to deploy an application that's failing its 
> unittests.

Overall a good idea, Andrei.

I take the opportunity to share a reoccurring dream of mine which 
is highly related to your proposal, Andrei:

I would like to have a compiler option for *automatic persistent 
memoization* of unittests that are inferred to be strongly pure.

Please take a moment to think about how your usage of unittests 
would change if this was available.

Eventhough D compiles faster than all other languages, big 
projects (including my single-developer ones) will eventually 
grow so large that always waiting for all unittests to compile 
and run will not be bearable to a developer.

The idea of persistent memoziation is not new (SCons does it an 
elegant with build artifacts). They just haven't been applied in 
as many cases as they could be.

In theory it's just a matter of hashing all the code and data the 
a unittest depends upon and using this hash as a memoization key 
for remembering if the unittest failed (and perhaps also how) or 
now. However, I'm not sure how the memoization keys should be 
calculated in practise. I do however know that the ELF file 
format contains a BuildID attribute calculated as a SHA-1. Is 
there any builtin support in ELF for hashing individual functions 
and data (sections)? Is there at all possible to figure out what 
code a unittest depends upon?

Please also think about how such a builtin feature would promote 
establishment and usage of D from a robustness and productivity 
point of view.