dunit r247

Christopher Wright dhasenan at gmail.com
Thu Mar 19 15:52:26 PDT 2009


bearophile wrote:
> Christopher Wright:
> 
> Having other testing frameworks/tools for D is good. There are many kinds of testing, and the built-in one isn't supposed to implement them all.
> 
> Regarding the issues of unit testing with unittest{}, I think the built-in unittesting has to be improved, to removed some of such issues. I am not looking for an universal and perfect built-in unittesting, and I think the built-in unittesting has to be kept simple, but the following things have to be fixed, maybe Walter will eventually understand why they are important:
> - Unittests are not labeled.
> - There is no output that specifically indicates that the tests were run.
> - A failing test will prevent any other tests from running. 
> - There is no indication of which test failed, if any.
> Such things are bare-bone functionality for any unit testing system.
> And I'd like to add a way to unittest at compile time too, to test types, templates, etc. (Until few weeks ago I didn't know any way at all to do this, then someone has given me a hint).

What are you using for this? __traits(compiles) works for d2, to an 
extent, and for d1, is (typeof(expression)). But for templates that have 
to be mixed into some context, that's more tricky.

> What's the advantage of:
> expect(foo(5), equals(3) | greaterThan(5));
> Compared to:
> expect(foo(5) == 3 | foo(5) > 5);

What error message should that give?

The former gives:
Expected: equal to 3 or greater than 5
But was: <whatever value foo(5) returned>

The latter gives:
Assertion error

>> If you write Dunit tests in separate modules, while your production code doesn't include dunit, you cannot test private methods. Dunit encourages the practice of separating tests and modules.<
> 
> For me it's often better to keep tests very close to the things they test. It helps me spot and fix bugs faster, to avoid jumping across files, and when I quickly move a block of code (function, class, template, etc) when I reorganize the code it is less likely for me to lose its tests along the way. I think tests are a part of a function/class/template, just like its ddocs.

I believe that there is a benefit to keeping the tests close to the 
tested code. I have not noticed a significant lack, however, when using 
junit or nunit.

> Bye,
> bearophile


More information about the Digitalmars-d-announce mailing list