------- Comment #6 from  2009-03-22 06:08 -------
(In reply to comment #5)
> (In reply to comment #0)
> > The current unit tests lack some functionality. 
> > - The current unit tests are not named.
> > - There is no output that specifically indicates that the tests were run.
> I often put writefln statements in my unittests, which seem to solve that
> problem.

Adding writefln is ok, but it's an implicit way of documenting the unittest.

> > - A single failing test will prevent all other tests from running.
> > - There is no indication of which test failed.
> If, as in your example, all assert statements are within the unittest code,
> then how is the line number in the assert error message not an indication?
> If you're calling functions to do the asserts, and so you can't tell what in
> the unittest triggered it, then the aforementioned writefln statements are one
> way around it.
> > unittest ("XML") {
> Why make the unittest names strings, rather than identifiers?

I agree that finding the failing assertion is not difficult, the difficultly is
working out what the failing test is meant to be doing. The reason for naming
and nesting, is that it groups related tests together and gives a description
to them, this is the reason why strings are preferred to identifiers. 

> So if I'm understanding correctly:
> - Each unittest block would have a pass/fail condition.


> - When an assert is thrown, the immediately containing unittest fails and 
> exits
> immediately.


> - If one unittest fails, the next will be run, but any unittest it's nested
> within would fail.

Any unittest it nested would not be executed, so they don't fail they are

> ... Moreover, would it be legal for statements to follow
> nested unittests within a unittest?  How would these be handled?

No reason to prevent statements between unittests, if a statement throws an
exception that will be treated as a failure of that unittest.


Reply via email to