std.unittests for (final?) review

[spir]

On Mon, 03 Jan 2011 12:27:33 -0800
Walter Bright <newshound2 at digitalmars.com> 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