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
+1, unittest passed as command line argument to dmd should run
unittests as compilation step and main should remain untouched.
