[py-dev] Does each test method get called with a new instance?

[David Ripton]

On 2005.04.08 01:18:21 +0000, holger krekel wrote:
> > I like the idea that each test case is completely independent of every 
> > other test case.  In other words, I prefer a new TestClass instance for 
> > each test case.  This will also make it more like unittest (it's fine 
> > to innovate when there's a significant improvement, but change for the 
> > sake of change is less attractive).
> 
> ok, but i am still interested in more opinions.  The thing is that

Re-initializing by default feels cleaner to me.  It's what xUnit users
expect.  Though of course it needs to be possible to override this and
explicitly reuse something expensive like a database connection.

> > I also don't see the need for all of setup_module, setup_class, and 
> > setup_method.  I only really see real setup scenarios -- stuff that 
> > should be done once, and stuff that should be done for every test case. 
> 
> "should be done once" is a matter of defining the specific scope. 
> per-modules, per-class and per-method seems like a natural choice
> to me.  In addition i would bet that if we didn't have setup_method 
> then people would say "but unittest has setUp and tearDown! where is it
> in py.test?", clearly at least a marketing catastrophe :-) 

I think all three are useful, even though it's unlikely that the same
module would use all three.  They're simple and orthogonal enough that I
think this is useful variety rather than feeping creaturism.

setup_module is useful for reusing database connections across a
multi-class test.  Also for when you have expensive test initialization
but no test classes because you've chosen to use top-level test
functions instead.

setup_class lets you put multiple test classes that have different
expensive initialization in one file, rather than making you split them
up into separate files to use setup_module.

setup_method is necessary because unittest has it.  The ability to
translate existing unittest modules to py.test with no thinking required
is key if you want unittest users to switch their existing projects,
rather than waiting until their next project to switch.  (Ideally, there
shouldn't be any grunt work either -- a unittest_to_pytest script would
be nice to have, even if it wasn't 100% perfect.)

-- 
David Ripton    dripton at ripton.net