Re: [Pyunit-interest] Avoiding side-effects in differnet tests

[Jason S. <jh...@oe...>]

Steve, thank you very much for all of your clarifications.

Steve Purcell wrote:
> Hello Jason,
> 
> I'm afraid that, as you have discovered, your assumption is not valid.
> 
> The setUp and tearDown methods are explicitly responsible for resetting 
> global state such that running a particular test will have no effect upon 
> the following tests.

After more reflection, I think this is the ideal thing to do.  For 
example, if it happened my way, I would not have found the threading 
lock bug that was causing a deadlock.  I think the ideal setUp() should 
set all global state, and the corresponding ideal tearDown() should 
assert that the state has been restored.  (But then there should not be 
much module global state, should there?  See below.)

> Unit tests typically test individual classes, a new instance of which is 
> created in setUp() or elsewhere for each test that is run. In your 
> situation, your tested unit is a module rather than a class, and the 
> equivalent of creating a new instance for each test would be reload()-ing 
> the method in each setUp() method. This is somewhat messier, and subject to 
> the vagaries of name bindings and import mechanisms.

Yes I came from sys admin, so I am only now learning good TDD practices.  :)

-- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
http://oes.co.th