On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
Have a look at https://github.com/linkrope/dunit, especially at
the "Related Projects".

Until now, my preferred tool for (large-scale) unit testing in D
would be the combination of my dunit framework (of course),
DMocks-revived for mocks, and the 'must' matchers of specd.

How does your toolkit fit in?

I looked at DMocks and Specd before i started work on DUnit to see what was out there. I'm not saying that DUnit does anything really different than those two combined but i'm trying to make it simpler to use and more intuitive.

For example DMocks uses an intermediary object to handle the mocks. This is thought was a bit strange as this behaviour should be in the mock to begin with. So my first objective was to provide a way of very simply creating a mock object and to interact with that mock object directly. This also fulfilled the secondary objective of moving 'setup' code out of the unit test and making them more easy to read. Also DUnit solved the problem that Dmocks doesn't address of correctly handling Object base class methods properly. All methods can fall-through to parent implementations or be replaced at runtime.

Specd is a nice approach to defining constraints but again it seems overkill for something that should be simple. I don't do anything different, i just do it in a different way.

    specd: 1.must.be.greater_than(0);
    dunit: 1.assertGreaterThan(0);

The reason i've gone with just providing more specific assert methods is that i can create nice helpful error message when things go wrong. For example this line:


Creates this error:

    | Failed asserting equal
    | File: example.d
    | Line: 85
    | ✓ Expected int: 1
    | ✗ Actual int: 2

Making debugging what went wrong loads easier. These messages give you so much useful info that you will never go back to only using assert() again.

Reply via email to