dunit r247
Nick Sabalausky
a at a.a
Thu Mar 19 10:38:30 PDT 2009
"bearophile" <bearophileHUGS at lycos.com> wrote in message
news:gptoms$bmm$1 at digitalmars.com...
> 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's the advantage of:
> expect(foo(5), equals(3) | greaterThan(5));
> Compared to:
> expect(foo(5) == 3 | foo(5) > 5);
> Or:
> auto aux5 = foo(5);
> expect(aux5 == 3 | aux5 > 5);
> ?
>
>>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.
>
Seconded, with the additional reason that I've found unittests to be an
incredibly useful form of documentation-by-example. There have been numerous
occasions where I've read documentation that still left me with questions,
so I opened up the actual source to see what was going on, saw the
unittests, and thought "A-ha! So that's how it's used! And I *know* it's
correct because it's part of the unittest."
More information about the Digitalmars-d-announce
mailing list