Utah Valley University teaches D (using TDPL)

[Fawzi Mohamed]

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