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

[holger krekel]

Hi Roy, 

On Thu, Apr 07, 2005 at 18:46 -0400, Roy Smith wrote:
> On Apr 7, 2005, at 5:17 PM, holger krekel wrote:
> >
> >Howering-the-however, such incremental testing is fragile with respect
> >to "--session" mode which reruns only failing tests.
> 
> Is --session documented anywhere?  I couldn't find it.
> 
> >Ok, ending these complicated considerations, i am 50:50 in
> >instantiating the TestClass on every test method invocation.
> >Anybody wants to weigh in on this detail?
> 
> 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
i currently think that it could make things slightly less nice 
in the implementation.  The current collect-py branch has  
rather general semantics for collecting objects.  As an illustration, 
this is the output from "py.test --collectonly test_util.py" 
(in the branch): 

<Module 'test_util.py'>
    <Class 'TestReport'>
        <Instance '()'>
    <Class 'TestStatus'>
        <Instance '()'>
            <Function 'test_init_with_None'>
            <Function 'test_str'>
            <Function 'test_init_with_bad_name'>
            <Generator 'test_init_with_good_name'>
                <Function '[0]'>
                <Function '[1]'>
                <Function '[2]'>
                <Function '[3]'>
                <Function '[4]'>
            <Function 'test_update'>
            <Function 'test_eq_'>

With instantiating per method this would become: 

    <Class 'TestStatus'>
        <Instance '()'>
            <Function 'test_init_with_None'>
        <Instance '()'>
            <Function 'test_str'>
        <Instance '()'>
            <Function 'test_init_with_bad_name'>
        ... 

Ugly, isn't it? :^) 

> 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 :-) 

cheers, 

    holger