Reddit: why aren't people using D?

Lutger lutger.blijdestijn at gmail.com
Thu Jul 23 13:05:37 PDT 2009


Walter Bright wrote:

> Knud Soerensen wrote:
...
>> 
>> I think one of D's strongest points for people to make the switch is
>> build in unit testing. (at least this is the strongest point for me)
>> But the very simple implementation of unit testing in D nearly ruin the
>> advantage it gives. (see suggestion from the wishlist below)
> 
> Even at its very simple support, it's a huge win. It raises the bar on
> what is minimally acceptable, and has been responsible for a big
> improvement in the quality of Phobos.

It's interesting why unittest (and assert) are such big success. My idea is 
that it's not in spite of, but because of their utter simplicity. I 
speculate that if it would have been different, for example if you would had 
to create a new file for a unittest, it would not have been used so much.

 
...
> 
>> ** Unit test isolation
>> I would like to be able to isolate the unit test,
>> so that if one fail the next still runs.
> 
> You can do this by simply not using "assert" for the actual test. Use:
>    if (!x) writeln("test for x failed");
> instead of:
>    assert(x);
> You can, of course, make a template like Andrei's enforce() to make the
> if test and message a bit more convenient.

But within sight there is something much better. druntime defines a function 
setAssertHandler to configure a user defined function for handling 
assertions! Combine this with version(unittest) and the 
Runtime.moduleUnitTester callback et voila!: profit*

I still see two major points of improvement:

- unittests are anonymous things. It would be a big improvement to be able 
to say unittest("Test foobar") { } and retrieve the named test via the 
runtime provided hooks
- all unittests from one module are lumped together in it's ModuleInfo 
object. I would rather like to see an array of named unittests instead.

The rationale for these improvements is that the language and standard 
library only defines very minimal, low impact ways of writing tests. At the 
same time, the building blocks are provided to create more advanced tools. 

This way you can also start out writing simple tests, and then not have to 
rewrite those again when you want to use some fancy continuous integration 
suite for D. At the moment, it's simply not possible to progress to more 
elaborate testing without breaking everything and starting from scratch. 


* Well I think so, I haven't been able to make use of it (segfaults) but it 
would be sweet.




More information about the Digitalmars-d mailing list