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

[holger krekel]

On Tue, Apr 05, 2005 at 17:24 -0500, Ian Bicking wrote:
> holger krekel wrote:
> >Effectively your above example would just lead to testing the
> >successful invocation of the __init__ constructor.  FWIW, a
> >more full blown example of what you might want to do is: 
> >
> >    def test_Test(): 
> >        datadir = py.magic.autopath.dirpath('data')  # [1]
> >        for inputfn in datadir.listdir('input*'): 
> >            newbasename = inputfn.basename.replace('input', 'output') 
> >            outputfn = inputfn.new(basename=newbasename) 
> >            yield Test(inputfn, outputfn) 
> >            # this assumes you want to run __call__ for the actual test 
> 
> Hrm... I see why my version wouldn't work like I want, but this isn't 
> actually what I'd want either.  I think there's a very useful pattern in 
> this case, where you'd want Test(...) to be an instance that would be 
> tested with py.test's full machinery -- meaning that all the test* 
> methods could be run, setup_method, etc.

Ah, i see where you are pushing me.  There might be ways to do
this, at least with the current py-collect branch.  I freely
admit that generative tests via yield started out as a hack to
accomodate criticism from some crazy guy, named Ian.  The
existence of this hack (and people appreciating it) was one of
the reasons for the py-collect branch which lead to the
collection & running process to converge significantly. 

> This is kind of coming back to me wanting the process of
> turning objects (like functions, classes, etc) into test
> items to be recursive, applied after generator functions
> parameterize the tests.  At least, I *think* that is what I
> wanted at one point... I am fickle and my desires are often
> short-lived ;)

For the time being, i would like to keep generative tests 
as simple as possible.  

> (Oh, BTW, both SQLObject and WSGIKit use py.test for all their testing 
> now -- this particular issue hasn't quite come up, but I think it may as 
> I increasingly build custom frameworks for their respective tests.  But 
> it's pretty low-priority compared to other things)

Good :-) 

> >[1] there it is again, the dreaded but convenient py.magic namespace: 
> >    py.magic.autopath() looks at your module's __file__ and gives 
> >    you a path object so that path.dirpath('data') gets you 
> >    to the 'data' directory accompanying your test file, irrespective
> >    of the current working directory. 
> 
> Yeah, I was just being sloppy in my example -- in real life I'd be using 
> os.path.dirname(__file__) and whatnot, all of which makes Python look 
> really really ugly ;)  I'm still feeling confused about whether to stick 
> with os.path -- stupid but familiar and doesn't put any runtime py lib 
> requirements on code -- or Orendorf's path module -- a little crufty, 
> but I really like the string subclass, because people can ignore its 
> specialness if they feel more comfortable with os.path -- or py.path, 
> which I'll admit is probably a more elegant interface.  One way or the 
> other, I feel like I have to *accept* string paths as arguments, and 
> path objects seem less compelling when I'm always instantiating new ones 
> and whatnot.  Hrm.  Not that I don't hate os.path, mind you.

I can understand all your reasonings here.  Let me note a few things: 

- py.path.local(py.path.local(X)) == py.path.local(X) 
  which means that you safely do: 

    def f(fn): 
        fn = py.path.local(fn) 

  without fearing a double-wrap. 

- str(path) gives you the plain string representation 

- if more people really want a string subclass it's not
  exactly hard to add it i guess 

So I consider "adds a runtime dependency" the heaviest argument. 

Btw, the py lib did get larger with time (and will continue to do so) 
but i still hold that the lib is far from becoming a framework because 
almost all of its parts are usable on their own without knowing 
about the others parts. 

cheers, 

    holger