I share the opinion others have expressed here that running unit
tests should be the responsability of the build system.
Atila
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.
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
