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