[py-dev] KeyboardInterrupt during setup() and teardown()

[holger krekel]

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 <holger at merlinux.eu
> ><mailto:holger at 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 at codespeak.net <mailto:py-dev at codespeak.net>
> > > > http://codespeak.net/mailman/listinfo/py-dev
> > >
> >
> >
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
>