Mailman 3 December 2007 - pytest-dev

Re: [py-dev] py.test generative tests unexpected behavior
by Jim.Vickroy＠noaa.gov Dec. 17, 2007

Dec. 17, 2007

----- Original Message ----- From: Carl Friedrich Bolz <cfbolz(a)gmx.de> Date: Monday, December 17, 2007 10:07 am Subject: Re: [py-dev] py.test generative tests unexpected behavior > Jim.Vickroy(a)noaa.gov wrote: > > > > ----- Original Message ----- > > From: Carl Friedrich Bolz <cfbolz(a)gmx.de> > > Date: Monday, December 17, 2007 8:25 am > > Subject: Re: [py-dev] py.test generative tests unexpected behavior > > > >> Hi! > >> > >> j. vickroy wrote: > >> [snip] > >>> The attached file (py-test-generator-trial.py) demonstrates a > >> behavior I > >>> do not understand. > >> [snip] > >> > >> I don't know generative test semantics all that well, I hoped > >> somebody > >> else would answer this. However, my theory is as follows: > >> > >> py.test first collects all the results of the generator and then > >> runs > >> them all. Since your test keeps global state, the state is > already > >> changed when the first test is run. To me this sounds like > >> reasonable > >> behavior, global state is not good in tests anyway. > >> > >> Does that make things clearer? > >> > >> Cheers, > >> > >> Carl Friedrich > >> _______________________________________________ > >> py-dev mailing list > >> py-dev(a)codespeak.net > >> http://codespeak.net/mailman/listinfo/py-dev > >> > > > > Thanks, Carl. > > > > I do understand (at least) some of the pitfalls of global state > and I do > > *almost always* avoid using it. However, in this case, I am having > > difficulty seeing why it is responsible for the observed behavior. > > I think what py.test does is essentially this: > > l = list(test_filters()) > # at this point source.info['palette'] == 'Gray' > # and that won't change any more > for t in l: > t[0](*t[1:]) # here the check functions are executed > > > > Having said that, prior to using the global *image* object, I > tried to > > use the setup_module(module) function to define the *image* > object but > > was unable to determine how to reference it in the test function. > > You can stick the the image into the module argument that the > setup_module function receives as first arg: > > def setup_module(mod): > mod.image = ... > > After the setup, the global name 'image' is bound to ... > This wouldn't have solved your problem, though, since it is still > global > state. > > [snip] > > Cheers, > > Carl Friedrich OK, it seems that module-level objects are not really suitable for use in the generative framework. Diagnostic statements show each test is actually being run twice and that the second running is where the failures occur. A work-around, in this particular situation, is to create a new test object for each iteration of the generator and that is not too expensive here, but I do have concerns about scalability of this approach. Thanks again for your follow-ups. --jv > _______________________________________________ > py-dev mailing list > py-dev(a)codespeak.net > http://codespeak.net/mailman/listinfo/py-dev >

1 0

Re: [py-dev] py.test generative tests unexpected behavior
by Jim.Vickroy＠noaa.gov Dec. 17, 2007

Dec. 17, 2007

----- Original Message ----- From: Carl Friedrich Bolz <cfbolz(a)gmx.de> Date: Monday, December 17, 2007 8:25 am Subject: Re: [py-dev] py.test generative tests unexpected behavior > Hi! > > j. vickroy wrote: > [snip] > > The attached file (py-test-generator-trial.py) demonstrates a > behavior I > > do not understand. > [snip] > > I don't know generative test semantics all that well, I hoped > somebody > else would answer this. However, my theory is as follows: > > py.test first collects all the results of the generator and then > runs > them all. Since your test keeps global state, the state is already > changed when the first test is run. To me this sounds like > reasonable > behavior, global state is not good in tests anyway. > > Does that make things clearer? > > Cheers, > > Carl Friedrich > _______________________________________________ > py-dev mailing list > py-dev(a)codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > Thanks, Carl. I do understand (at least) some of the pitfalls of global state and I do *almost always* avoid using it. However, in this case, I am having difficulty seeing why it is responsible for the observed behavior. Having said that, prior to using the global *image* object, I tried to use the setup_module(module) function to define the *image* object but was unable to determine how to reference it in the test function. The global *image* object was a crude work-around. Can you offer some suggestions on how I should have proceeded given that I really do not need to create a new *image* object for each test. Thanks again, -- jv

2 1

[py-dev] py.test generative tests unexpected behavior
by j. vickroy Dec. 17, 2007

Dec. 17, 2007

Hello all, I'm a first time user of py.tests. My setup is: * py.test v0.9.0 * Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 * Microsoft Windows XP Pro (service pack 2) The attached file (py-test-generator-trial.py) demonstrates a behavior I do not understand. When test_filters() is implemented as a generator, the tests appear to be run twice and all tests fail during the second iteration except for the final case ('AL12_1','Gray') in the loop. When the yield statement, in test_filters(), is disabled and the assertion statement is enabled, the behavior is as expected -- namely the tests are performed once and all pass. Could someone help me to understand this behavior? Thanks, --jv P.S. I could provide captured output if that is helpful. ''' unexplained behavior: py.test generative test appears to repeat tests USE: > py.test test_PNG_colorization NOTES: o Requires installation of py.test (http://codespeak.net/py/dist/test.html) AUTHOR: jim.vickroy(a)noaa.gov ''' from __future__ import absolute_import class Image(object): _palettes_ = { 'Flame' : ['OPEN'], # no filter 'Green' : ['PTHK_0'], 'Blue' : ['BE12A_0'], 'Gray' : ['AL12_1'], } def __init__(self): self.info = dict() def __str__(self): return self.__class__.__name__ source = Image() def process(source): filter = source.info['wavelnth'] processed = Image() processed.info = source.info for palette, filters in Image._palettes_.items(): if filter in filters: processed.info['palette'] = palette break else: raise NotImplementedError('no palette defined for the %s filter' % filter) return processed def test_filters(): for filter, palette in zip(('OPEN','PTHK_0','BE12A_0','AL12_1'), ('Flame','Green','Blue','Gray')): source.info['wavelnth'] = filter processed = process(source) print 'yielding:',check,processed,palette yield check, processed, palette # NOTE: this does not work as expected #~ assert processed.info['palette'] == palette, processed.info['palette'] # NOTE: this works as expected! def check(image,palette): print 'checking %s palette' % image assert image.info['palette'] == palette, image.info['palette']

2 1

[py-dev] Fwd: [Fwd: Re: py.test generative tests behavior unexpected]
by Jim.Vickroy＠noaa.gov Dec. 17, 2007

Dec. 17, 2007

1 0

[py-dev] username and password support for py.path.svnwc
by Martijn Faassen Dec. 12, 2007

Dec. 12, 2007

Hi there, Looking at the API and grepping around the source it seems there is no obvious support for username/password in py.path.svnwc. I'd like to be able to do a checkout as a particular user, and give a password programmatically. Is there any way I'm not seeing, or is this indeed a missing feature? I could spend a bit of time adding this, but I do need to have some idea of when a release will happen. Regards, Martijn

3 2