Utah Valley University teaches D (using TDPL)

Jonathan M Davis jmdavisProg at gmx.com
Fri Nov 26 17:37:04 PST 2010


On Friday 26 November 2010 17:17:56 bearophile wrote:
> Walter:
> > Yes, it is. Unit test failures return a non-zero exit code.
> 
> I see, good. But real unit test systems don't just return that value, they
> give a more visible feedback, like the number of failed/passed tests. One
> line of text that shows those numbers is a good start.

I'm a firm believer that D unit tests should not change how they fundamentally 
work at this point. I don't _want_ it to report the number of tests that passed. 
That information is not at all useful. And if I want to do something like set up 
something to run dmd periodically and report only when the tests start failing, 
then the current situation is perfect.

I _do_ think that the unit testing stuff should be expanded to have named unit 
tests and do whatever is necessary to make it possible for external tools to run 
the unit tests. Then you could have an external tool that did things like only 
run specific unit tests and report which tests succeeded and which failed.

So, I do think that it should be possible to build external tools on D's unit 
testing framework, but I think that it's quite good as it is now, and I wouldn't 
want to see it drastically changed.

The two changes that I want to see to the current framework are

1. Make it so that every unittest block runs in a module instead of them 
stopping once one failed. The current situation is better than stopping _all_ 
unittest blocks once a single test fails, but it's still not granular enough. I 
believe that this change is planned, but work has to be done to make it 
possible, and that work hasn't been done yet.

2. Make it possible to name unittest blocks. This would make exceptions that 
escape unittest blocks _far_ more useful. Names like unittest45 really aren't 
useful at all. I can't even figure out how it does the numbering. Also, having 
named unittest blocks would be a necessity for properly allowing external tools 
to run the unit tests.

I do _not_ want to see D programs printing out anything more than they do when 
running unit tests. I'm totally open to external tools which do more (it would 
particularly good for IDEs to be able to run unittest blocks individually), but 
I do not want to see the basic framework change how it prints feedback on test 
successes and failures. It works great as it is now.

- Jonathan M Davis


More information about the Digitalmars-d-announce mailing list