Hi Pärham, Ronny,
On Thu, Jul 12, 2012 at 15:26 +0200, Ronny Pfannschmidt wrote:
> Hi Pärham,
>
> as i already explained in irc before,
> a cached setup only calls tear-down if it was successful,
>
> and if you want it to work property, you should split it up
>
> an example of doing that would be something like
>
> def pytest_funcarg__app(request):
> def setup()
> return create_app() # FAST
> def teardown(app):
> app.stop()
> app = request.cached_setup(setup, teardown, scope='session')
> app.start() #can wait
> return app
I don't think this is correct as it would start() the app
in each test function that uses the "app" funcarg.
It's indeed unusual that despite a failing setup you
want to do some teardown. Maybe in this case controling
it yourself is the best:
def setup():
try:
app.start()
except Exception: # or KeyboardInterrupt etc.
app.stop()
raise
hth,
holger
> -- Ronny
>
> On 07/12/2012 02:12 PM, Pärham Fazelzadeh H wrote:
> >Hi Holger,
> >
> >
> >Here below is an example:
> >
> >def pytest_funcarg__app(request):
> >
> > def setup():
> > # Blocking call to start(), returns when application has
> >finished booting up
> >
> > app.start()
> >
> > return app
> >
> >
> > def teardown(val):
> >
> > app.stop()
> >
> > return request.cached_setup(
> >
> > setup=setup,
> >
> > teardown=teardown,
> >
> > scope='session',
> >
> > extrakey='app'
> > )
> >
> >
> >Now, during setup(), when the process is waiting for the app to boot, if
> >a keyboardinterrupt is raised (say by the user during from the test
> >execution summary screen) then it will not call the teardown() of this
> >funcarg 'app'. I assume this is because py.test assumes that the setup()
> >of 'app' has not been finished and therefor it is not in a proper state
> >for teardown() of 'app'.
> >
> >Regards,
> >Parham
> >
> >On 12 July 2012 12:05, holger krekel <hol...@merlinux.eu
> ><mailto:hol...@merlinux.eu>> wrote:
> > >
> > > Hi Pärham,
> > >
> > > On Thu, Jul 12, 2012 at 11:46 +0200, Pärham Fazelzadeh H wrote:
> > > > Hi all,
> > > >
> > > > I am using py.test to perform integration and functional testing of an
> > > > application and had some issues with interrupts and was advised to
> >submit
> > > > my use case.
> > > >
> > > > Basically the problem is related to funcargs and how setup() and
> >teardown()
> > > > are affected by interrupts. The issue we are having is that some of our
> > > > funcargs take longer to setup than what is maybe recommended. One
> >of the
> > > > funcargs instantiate and start the application that is to be tested and
> > > > this can take some time; in the setup() you basically wait for the
> > > > application to boot up to verify that it has started. If a
> > > > KeyboardInterrupt is raised during setup() it will leave the
> >application in
> > > > a dirty state since no teardown will be run, i.e the application
> >will be
> > > > left running. Similarly this can happen during configuration stages in
> > > > funcargs.
> > > >
> > > > I learned that this is default behaviour (and also reasonable),
> >seeing as
> > > > the idea is that funcargs should be small and be fast.
> > >
> > > funcargs with a longer setup are fine. I am not sure i understand
> > > how you are missing teardowns. How do you perform teardown, with
> > > request.addfinalizer()? Can you provide a little examples that reproduces
> > > the problem?
> > >
> > > best,
> > >
> > > holger
> > >
> > > > Still, this is our use case so here you go! :)
> > > >
> > > > Regards,
> > > > Parham
> > >
> > > > _______________________________________________
> > > > py-dev mailing list
> > > > py-dev@codespeak.net <mailto:py-dev@codespeak.net>
> > > > http://codespeak.net/mailman/listinfo/py-dev
> > >
> >
> >
> >_______________________________________________
> >py-dev mailing list
> >py-dev@codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
>
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
