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
I don't fully understand this. Are you proposing to disconnect
running unittest and evoking main? So unittests can be compiled
and run without actually running the program?
If this is the case then yes it would be nice to be able to do
this but i would also recommend keeping the current behaviour of
invoking main after the unittests have run, purely because
developers (myself included) like to run the application often in
debug/unittest mode during development.
