Collin Winter:
> [ improvements to unittest]
These would all have been (mostly) reasonable when the module was
first added to the standard library. But it has been there as an ugly
fragile unchanging beast for several years, and is ironically not well
endowed with unit tests. I therefore think
Collin Winter wrote:
> Any thoughts on the other four items?
Generally speaking, I'm not sure it's worth the effort to do the input
validation. All of the cases you suggest ruling out do indeed seem to be
insane, but someone may have defined a subclass that does something based on
the current b
On 8/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Alternatively, someone who prefers your style (with a tearDown() method that
> can handle a partially executed call to the setUp() method), can just write
> it as:
>
> def setUp(self)
> try:
> lock_file(testfile) # open_socket
On 8/19/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> 1) TestCase.tearDown() is only run if TestCase.setUp() succeeded. It
> seems to me that tearDown() should always be run, regardless of any
> failures in setUp() or the test method itself.
>
> The case I'm considering is something like this, ie,
Collin Winter wrote:
> [Sorry for accidentally cross-posting this to python-list]
>
> While working on a test suite for unittest these past few weeks, I've
> run across some behaviours that, while not obviously wrong, don't
> strike me as quite right, either. Submitted for your consideration:
>
>
[Sorry for accidentally cross-posting this to python-list]
While working on a test suite for unittest these past few weeks, I've
run across some behaviours that, while not obviously wrong, don't
strike me as quite right, either. Submitted for your consideration:
1) TestCase.tearDown() is only run
