blerp 0.1.1

Better test output for D's integrated unittesting

To use this package, run the following command in your project's root directory:

Manual usage
Put the following dependency into your project's dependences section:


Blerp is a library for D which blerps out all the unittests that were ran and logs the number of succeeded and failed tests. Because by default, D doesnt really print anything useful if all tests pass.

Blerp discovers tests at compile time.

Blerp allows you to name your tests too!

It doesnt do anything clever like colour the output atm.

Including blerp in your project

Blerp is available on the dub package hub. Inside your package's directory, run:

dub add blerp

You can also install it manually: Clone blerp, and run the following inside your package directory:

dub add-local path-to-blerp

before adding the snippet:

        "version": "~master"

to your dub.json.

At the top of one of your project's files, include:

    import blerp.blerp;
    static this()
        import core.runtime;
        Runtime.moduleUnitTester = { return true; };

import blerp.blerp: BlerpTest;

That overrides the default test runner, and runs blerp's.

Include the following at the top of all other files with tests in them:

    import blerp.blerp;
    static this()

import blerp.blerp: BlerpTest;

Making tests discoverable by Blerp

Simply add the BlerpTest UDA to every test you wish Blerp to run.

@BlerpTest("test_my_test_name") unittest
    writeln("My Unittest");

Example output

The below shows an example of some test output, including multiple modules, and a failed test.

Generating test runner configuration 'blerp-test-library' for 'library' (library).
Performing "unittest" build using /usr/bin/dmd for x86_64.
blerp ~master: building configuration "blerp-test-library"...
Running ./lib/blerp-test-library 
==================================  BLERP  ==================================
1 Tests Failed 0 Tests Succeeded
unittest failure
core.exception.AssertError@source/example.d(14): unittest failure
PRunning ./lib/blerp-test-library 
==================================  blerp.example  ==================================

PASSED    blerp.example.unittest_one
FAILED    blerp.example.Unittest_two
PASSED    blerp.example.hello

3 Tests Ran
1 Tests Failed and 2 Tests Succeeded.

==================================  blerp.example.Unittest_two  ==================================

unittest failure
??:? _d_unittestp [0x560115687add]
source/example.d:35 void blerp.example.__unittest_L33_C28() [0x560115685111]
source/blerp/blerp.d:69 bool blerp.blerp.runTests!("blerp.example").runTests() [0x560115683d20]
source/example.d:11 void blerp.example._staticCtor_L9_C20() [0x560115685090]
??:? void blerp.example.__modctor() [0x560115685124]
??:? void rt.minfo.runModuleFuncs!(rt.minfo.ModuleGroup.runTlsCtors().__lambda1).runModuleFuncs(const(immutable(object.ModuleInfo)*)[]) [0x5601156aacca]
??:? void rt.minfo.ModuleGroup.runTlsCtors() [0x5601156aa994]
??:? int rt.minfo.rt_moduleTlsCtor().__foreachbody1(ref rt.sections_elf_shared.DSO) [0x56011568ce60]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x56011568d384]
??:? rt_moduleTlsCtor [0x56011568ce40]
??:? rt_init [0x5601156892d3]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x560115689883]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x560115689820]
??:? _d_run_main2 [0x560115689788]
??:? _d_run_main [0x560115689505]
/usr/include/dlang/dmd/core/internal/entrypoint.d:29 main [0x560115673951]
??:? __libc_start_main [0x7fc9184e6022]

==================================  example2  ==================================

          Ignoring test example2, it is not marked as a BlerpTest

0 Tests Ran
0 Tests Failed and 0 Tests Succeeded.

All unit tests have been run successfully.
Program exited with code 1


1: Will Blerp have coloured output

Ugh, eventually. But most existing terminal colouring libraries won't work at compile time, and I have yet to write my own.

2: Can I run tests selectively?

Not at the moment, this is something I'd like to support.

3: Why do I have to put stuff at the top of every file. Why isnt it magic!

Because Blerp needs the name of the module do discover and run tests. moduleUnitTester gets defined in only one module, and therefore you can only pass through the name of the module you defined it in. So, we must call a test runner with the module name, in each module.

This might change if I figure out how to get a list of all modules in the package.

4: Will you put this on dub?

At some point.

5: Can I use this in production?

Probably? Its not got that many moving parts. If you do, I'd be thrilled to know.

  • Samathy Barratt
0.1.1 2020-May-16
0.1.0 2020-May-15
~master 2020-May-16
Show all 3 versions
Download Stats:
  • 0 downloads today

  • 0 downloads this week

  • 0 downloads this month

  • 0 downloads total

Short URL: