Utah Valley University teaches D (using TDPL)

[Jonathan M Davis]

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.

Adding named unit tests and making it possible to call locate and call unit 
tests functions externally would make it possible to have an IDE or some other 
external tool deal with unit test successes and failures in a manner closer to 
what you're looking for, and I think that that sort of thing would be a definite 
step forward, but what we have works quite well. I think that extensions to it 
(like adding names to unit tests) would be great, but the only major change that 
I can think of which really needs to be made (rather than an extension) would be 
to make it so that all unittest blocks in a module run independently so that 
they all run regardless of whether any others fail (and I think that that change 
is supposed to be being done at some point). Making changes such as making 
unittest blocks print on success is not something that I would consider a good 
change (though making it possible wouldn't necessarily be bad).

> > particularly when it's not all that hard
> > to add code yourself which prints out success if you really want it to.
> 
> It's also not hard to define global functions, wrapped in a
> version(unittest){}, to replace the need of the unittest keyword (unittest
> becomes a version ID).

Almost, but not quite. -unittest also enables assertions if they would otherwise 
be disabled, which a simple version couldn't do.

- Jonathan M Davis