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> 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
> > http://codespeak.net/mailman/listinfo/py-dev
>
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
