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

[Ronny Pfannschmidt]

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