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
