Parallel execution of unittests

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Thu May 1 12:47:36 PDT 2014


Am Thu, 01 May 2014 12:26:07 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 5/1/14, 12:05 PM, Johannes Pfau wrote:
> > Here's the revived pull request:
> > https://github.com/D-Programming-Language/dmd/pull/3518
> > https://github.com/D-Programming-Language/druntime/pull/782
> 
> I'm unclear what this work does even after having read the
> description. What does it require in addition to just sprinkling
> unittests around? -- Andrei

Nothing. This just changes the way druntime internally handles the
unit tests, but nothing changes for the user:

Right now we have one function per module, which calls all unit tests
in these modules, but the test runner does not have access to the
individual unittest functions.

Instead of exposing one function per module, this now exposes every
single unittest function. So you can now run every test individually or
pass the function pointer to a different thread and run it there.

Additionally this provides information about the source location of
every unit test. I thought the example is quite clear?
-------------
bool tester()
{
    import std.stdio;
    //iterate all modules
    foreach(info; ModuleInfo)
    {
        //iterate unit test in modules
        foreach(test; info.unitTests)
        {
            //access unittest information
            writefln("ver=%s file=%s:%s disabled=%s func=%s", test.ver,
test.file, test.line, test.disabled, test.func); //execute unittest
            test.func()();
        }
    }
    return true;
}

shared static this()
{
    Runtime.moduleUnitTester = &tester;
}
-------------


You customize the test runner just like you did before, by setting
Runtime.moduleUnitTester in a module constructor.

Now you still have to implement a custom test runner to run unittest in
parallel, but that's trivial. We can of course add an implementation
this to druntime, but we can't use std.parallelism there.



What's a little more complicated is the versioning scheme, but that's
an implementation detail. It ensures that we can change the exposed
information (for example if we want to add a name field, or remove some
field) without breaking anything.


More information about the Digitalmars-d mailing list