Re: [py-dev] KeyboardInterrupt during setup() and teardown()
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
Re: [py-dev] KeyboardInterrupt during setup() and teardown()
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
Re: [py-dev] KeyboardInterrupt during setup() and teardown()
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
Re: [py-dev] KeyboardInterrupt during setup() and teardown()
Hi all, my bad, that start call should have been named ensure_started On 07/12/2012 10:30 PM, holger krekel wrote: 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 http://codespeak.net/mailman/listinfo/py-dev ___ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
