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