----- Original Message ----
> From: Brad Roberts <[email protected]>
> I fully agree
> that with D that it's unlikely that I'd leave unit tests
> turned on in
> production builds -- but if the tests are fast enough to
> leave in, no real
> harm either. Keep in mind, they don't affect anything
> beyond the cost
> of app startup, or
> shouldn't.
But we should not try to optimize unittests, they are not there for
performance, they are there for diagnostics. Make them as comprehensive and
useful as possible, performance be damned.
My first point should explain why you should never leave them in -- they don't
depend on anything but hard-coded values. Therefore, they are almost entirely
deterministic (you could argue that unit testing could potentially open files
or something, but that is unlikely), and running them more than once is a
complete waste of CPU cycles.
But I meant that when unittests were disabled, the assert handler linked would
be the faster variety, and when unittests were enabled, the assert handler
would be the comprehensive unittesty variety. The object files would be
identical, it's just what assert function do you link with. I don't know if
it's possible, which is why I asked.
If that's not possible, we still have another option.
An assert translates roughly to this:
if(!condition) {throwAnError();}
We all agree that when throwAnError is called, performance is out the window
(nobody but the runtime should be catching asserts, and we should expect the
program to exit soon after since it's in an invalid state). Why can't the
check for whether we're in unittest mode be inside that function/block as
Andrei pointed out? My larger point is simply that we should not consider
performance problems to be important during unit testing, asserts can be slow,
because unittests do not need to be as fast as possible.
-Steve
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
