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

[Ian Bicking]

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.  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 ;)

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

> [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.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org