Author fperez
Recipients brian.curtin, exarkun, fperez, michael.foord, pitrou
Date 2010-02-11.23:48:42
SpamBayes Score 3.77949e-08
Marked as misclassified No
Message-id <1265932125.77.0.101493183864.issue7897@psf.upfronthosting.co.za>
In-reply-to
Content
I should probably have clarified better our reasons for using this type of code.  The first is the one Michael pointed out, where such parametric tests all execute; it's very common in scientific computing to have algorithms that only fail for certain values, so it's important to identify these points of failure easily while still running the entire test suite.  

The second is that the approach nose uses produces on failure the nose stack, not the stack of the test. Nose consumes the test generators at test discovery time, and then simply calls the stored assertions at test execution time.  If a test fails, you see a nose traceback which is effectively useless for debugging and with which using --pdb for interactive debugging doesn't help much (all you can do is print the values, as your own stack is gone).  This code, in contrast, evaluates the full test at execution time, so a failure can be inspected 'live'.  In practice this makes an enormous difference in a test suite being actively useful for ongoing development where changes may send you into debugging often.

I hope this helps clarify the intent of the code better, I'd be happy to provide further details.
History
Date User Action Args
2010-02-11 23:48:46fperezsetrecipients: + fperez, exarkun, pitrou, michael.foord, brian.curtin
2010-02-11 23:48:45fperezsetmessageid: <1265932125.77.0.101493183864.issue7897@psf.upfronthosting.co.za>
2010-02-11 23:48:43fperezlinkissue7897 messages
2010-02-11 23:48:42fperezcreate