dunit r247

[Nick Sabalausky]

"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."