On 18-nov-10, at 09:11, Don wrote:
Jonathan M Davis wrote:
On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
Jonathan M Davis:
Most of the rest (if not all of it) could indeed be done in a
library.
I am not sure it could be done nicely too :-)
That would depend on what you're trying to do. Printing test
success or failure is as simple as adding the approprate scope
statement to the beginning of each unittest block. A bit tedious
perhaps, but not hard.
Right now
unit tests follow the unix convention of saying nothing on success,
That's an usability failure. Humans expect feedback, because you
can't tell
apart "unittests run and succeed" from "unittests not even run".
That Unix
convention is bad here. And Unix commands sometimes have a -v
(verbose)
command that gives feedback, while D unittests don't have this
option.
I'm afraid that I have to disagree there. Having all of the
successes print out would, in many cases, just be useless output
flooding the console. I have no problem with making it possible for
unit tests to report success, but I wouldn't want that to be the
default. It's quite clear when a test fails, and that's what is
necessary in order to fix test failures.
I can see why a beginner might want the positive feedback that a
test has succeeded, but personally, I would just find it annoying.
The only real advantage would be that it would indicate where in
the unit tests the program was, and that's only particularly
important if you have a _lot_ of them and they take a long time to
run.
I think: "%d unit tests passed in %d modules"
would be enough.
This was already discussed, I think that optimal solution would be to
have a testing function a bit like tangos, the testing functions knows
how the module is called. Tango one always prints the module, but that
is easy to change.
What I use is my own testing framework, in it i have defined as
default main function that checks commandline arguments, so that one
can for example pass --print-level=error and see only the errors...
See http://dsource.org/projects/blip/wiki/BlipOverview for an example
of using it.
This means having a special file to compile, that generates an
executable dedicated to testing, but this maps well to how I do tests.
In fact I often keep the tests separated from the code, I even hide
them behind templates to avoid excessive template instantiation in
some cases because they are large and would slow down the compilation...
The current default unittest function runs very early (before main),
so it is not possible to use that and use commandline arguments (which
is "correct" because in the current model unittests can be activated
for *any* executable, and should not disturb its run).
It should be possible to write a test function that just sets up
things for a later real unittest run that starts from main and can
parse the commandline arguments, thus solving all these discussions...
Fawzi
