[issue2578] additional unittest type equality methods

Changes by Steve Purcell : -- nosy: -purcell ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Steve Purcell added the comment: Sounds good to me. -- ___ Python tracker <http://bugs.python.org/issue5538> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Steve Purcell added the comment: Indeed -- if some of the setUp code is likely to fail, that should be handled right there in setUp, by reversing any other setup code that may have executed. It's harder to write a tearDown that will work reliably for any partially successful

[issue4444] unittest - use contexts to assert exceptions

Steve Purcell <[EMAIL PROTECTED]> added the comment: I like this change, since assertRaises can be a bit messy when passing it a local function. I'd suggest modifying the patch such that the AssertRaisesContext class is also used when callableObj is provided, which would el

[issue2578] Figure out what to do with unittest's redundant APIs

Steve Purcell <[EMAIL PROTECTED]> added the comment: Hey, I came to Python from Perl, Java *and* C++! I'm pretty sure the xUnits in all those other languages hold to the same basic API. Adding more TestLoaders/TestRunners sounds like an excellent move. I'd expect that o

[issue2578] Figure out what to do with unittest's redundant APIs

Steve Purcell <[EMAIL PROTECTED]> added the comment: Hey, I'm open to anything. If I started writing unittest from scratch knowing what I know now, I'd probably have kept the API a little slimmer. Oh, and I'd have named everthing according to Python conventions; m

[issue2249] To document "assertTrue" in unittest

Steve Purcell <[EMAIL PROTECTED]> added the comment: +1 for applying Alexander's patch, then; I'll leave the decision to a current committer. __ Tracker <[EMAIL PROTECTED]> <http://

[issue2249] To document "assertTrue" in unittest

Steve Purcell added the comment: I could be convinced either way here, and Georg & Raymond always have excellent judgement. My personal inclination would probably be to add the documentation for assertTrue() and also assertFalse(), since their naming is symmetrical with that of assertE

[issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error)

Steve Purcell added the comment: Hi Brian - thanks for going into some details of your rationale! You might be surprised to hear that it's indeed possible to make all of your unit tests mutually independent; check out the area of 'mock objects'. It turns out to be possi

[issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error)

Steve Purcell added the comment: I guess I don't completely agree with the rationale, because I've never wanted this feature; when running tests en-masse after refactoring, I want an overview of what was broken. If the codebase is in good shape, the test failures will be few

[issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error)

Steve Purcell added the comment: Hi Brian; The module is intended for test suites where the unit tests are written to be independent of each other, which is the "standard" way to do things. Note, for instance, that there is no convenient support for changing the order in which

[issue2156] TestCase.tmpdir(), TestCase.mock()

Changes by Steve Purcell: -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2156> __ ___ Python-bugs-list mailing list Uns

[issue2156] TestCase.tmpdir(), TestCase.mock()

Steve Purcell added the comment: I agree with Raymond: -1 from me. There isn't a consensus on what "mock object" means*, and trying to provide a standardised mock object facility is a quagmire*, hence the prior rejections to which Raymond refers. It's easy to roll

[issue2153] unittest.py modernization

Steve Purcell added the comment: Yes indeed - you're exactly right; just checked now. Then disregard my previous comment! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue2153] unittest.py modernization

Steve Purcell added the comment: Hi Virgil; thanks for stepping up to this. Backward compatibility was largely for the sake of compatibility with Jython, which was always lagging far behind CPython. I doubt it's a concern these days, and the unittest.py in the Python source repos

[issue1705520] pyunit should allow __unittest in locals to trim stackframes

Steve Purcell added the comment: This is a good idea, but slightly messy. A better solution would be for unittest to provide a decorator that could be used to mark assertion functions. Internally, that decorator may well work the way you describe. Given a corresponding patch, someone with

[issue1034053] unittest.py patch: add skipped test functionality

Steve Purcell added the comment: The status of this ticket is unchanged. I'm somewhat removed from the Python scene in recent times, and I'm not in a position to apply this patch or a variation of it. I still believe this would be a beneficial change to the unittest module, t