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