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.
