On Mon, 03 Jan 2011 12:27:33 -0800
Walter Bright <[email protected]> wrote:
> On the other hand, the built-in D unit test ability has been a huge success.
>
> A unit test facility that is not used is worthless, no matter how capable it
> is.
> The advantage of it being simple and built-in is it gets used, and I think
> there's strong evidence that this is true for D.
Unfortunately, I find D's builtin unittest way non-convenient for the single
reason they are unnamed (so do other D programmers). I have one & only one
final unittest block controlling a bunch of (named!) test funcs, in each module:
// === test ==========
void testFeature1 () {
...
}
void testFeature2 () {
...
}
void testFeature3 () {
...
}
unittest {
testFeature1();
testFeature2();
testFeature3();
}
That way, at any moment, I can run exactly the test func(s) related to the part
or aspect of the app I'm currently working on. A side advantage of this
practice is that I can switch off all tests of a given module (esp when working
on another one that imports it) by simply commenting out the control block.
Let unittests be named and D's way will be, for me, perfect in both simplicity
and practicality:
unittest feature1 {
...
}
unittest feature2 {
...
}
unittest feature3 {
...
}
unittest {
feature1;
feature2;
feature3;
}
(Note this is an additive feature, I guess: would be backward compatible,
provided unnamed unittests remain automatically run (with --unittest); the
'top' one would be unnamed.)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
