Extending unittests [proposal] [Proof Of Concept]

Jacob Carlborg doob at me.com
Fri Sep 21 02:25:10 PDT 2012


On 2012-09-20 23:14, Jonathan M Davis wrote:

> Running more unittest blocks after a failure is similarly flawed, but at least
> in that case, you know that had a failure earlier in the module, which should
> then tell you that you may not be able to trust further tests (but if you
> still run them, it's at least then potentially possible to fix further failures
> at the same time - particularly if your tests don't rely on external state).
> So, while not necessarily a great idea, it's not as bad to run subsequent
> unittest blocks after a failure (especially if programmers are doing what
> they're supposed to and making their unit tests independent).

I don't agree. I think that if you designed your unittests blocks so 
they depend on other unittest blocks are equally flawed. There's a 
reason for that most testing frameworks have "setup" and "teardown" 
functions that are called before and after each test. With these 
function you can restore the environment to a known state and have the 
tests keep running.

On the other hand, if there's a failure in a test, continue running that 
test would be quite bad.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list