Mailman 3 September 2012 - pytest-dev

[py-dev] using logging in py.test
by Anton P Oct. 1, 2012

Oct. 1, 2012

Hi All, I'd like to use standard logging module with py.test. Messages generated from test functions are visible on stdout if -s option is set. But log messages generated from conftest.py or other custom modules used inside test function are not visible on stdout but visible in captured stdout in case -s option isn't set. I want to see all the messages from all modules on stdout, not only from test function. Could anybody point me to the root couse of the issue? Thank you in advance! -Anton

2 2

[py-dev] performance timing and timer pausing in pytest-timeout
by Floris Bruynooghe Sept. 30, 2012

Sept. 30, 2012

Hi all, While pytest-timeout was targeting hanging/deadlocked code there have been various requests which relate to failing tests based on performance. Another issue which came up is the control of timeouts during fixtures (funcarg/resource) setup. So instead of saying that this is not in the scope of pytest-timeout as I have been doing so far here is a proposal of how to address these requirements. I'd be very grateful on any feedback you could provide. Firstly I'd like to introduce a timeout funcarg resource which allows you do to things like this:: @pytest.funcarg() def shared_resource(timeout): with timeout.pause(), timeout.skip(30): return acquire_shared_resource() Some details: timeout.pause: context manager to pause the normal timeout timer if one is active. timeout.skip and timeout.fail: These are context managers which will try to "soft" timeout the code block within them. This means if reasonably possible it will try to interrupt the code block after the timeout, but if not it will just run the code block until it finished. Either way when exiting the context manager either Skip or Fail will be raised. Also no extra information like e.g. thread and stack details will be provided. It's full signature will probably something like timeout.skip(timeout, timer=time.time, msg=None) where the idea is to provide some timers in the pytest namespace like pytest.timer_ms, pytest.timer_pystone. This can be useful in both fixtures as well as test functions. Lastly I'm thinking of providing a way of getting a timer which uses pytest-cache and to measure the duration of a test (in pystones) and will fail the test if it takes longer then the previous pystones value. This would only be reset by clearing the cache. I'm not sure whether to do this as part of the new timeout funcarg resource or as a new marker,so either:: def test_foo(timeout): with timeout.noregress(): performance_critical_func() or:: @pytest.mark.timeout_noregress def test_foo(): performance_coritical_func() Both version could probably take a timer argument too re-using the pytest.timer_ms, pytest.timer_pystones etc timers. I'm slightly in favour of the context manager since it makes the timed section more explicit. But it might possibly only be allowed once per test function (or have a "key" argument). I'm very keen to hear other people's input on these ideas before implementing them. Especially since they solve problems I don't really have personally. Regards, Floris

2 1

[py-dev] [hpk42/pytest] node.keywords no longer writable (issue #194)
by Ronny Pfannschmidt Sept. 29, 2012

Sept. 29, 2012

--- you can reply above this line --- New issue 194: node.keywords no longer writable https://bitbucket.org/hpk42/pytest/issue/194/nodekeywords-no-longer-writable Ronny Pfannschmidt: due to vars(self.markers) being a nonwritable dictview now -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] [hpk42/pytest] os module has no attribute 'fork' on Windows (issue #193)
by Anonymous Sept. 27, 2012

Sept. 27, 2012

--- you can reply above this line --- New issue 193: os module has no attribute 'fork' on Windows https://bitbucket.org/hpk42/pytest/issue/193/os-module-has-no-attribute-for… Anonymous: executing py.test --boxed on Windows failed with the error: Traceback (most recent call last): File "c:\python27\lib\site-packages\_pytest\main.py", line 74, in wrap_session doit(config, session) File "c:\python27\lib\site-packages\_pytest\main.py", line 106, in _main config.hook.pytest_runtestloop(session=session) File "c:\python27\lib\site-packages\_pytest\core.py", line 421, in __call__ return self._docall(methods, kwargs) File "c:\python27\lib\site-packages\_pytest\core.py", line 432, in _docall res = mc.execute() File "c:\python27\lib\site-packages\_pytest\core.py", line 350, in execute res = method(**kwargs) File "c:\python27\lib\site-packages\_pytest\main.py", line 119, in pytest_runtestloop item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem) File "c:\python27\lib\site-packages\_pytest\core.py", line 421, in __call__ return self._docall(methods, kwargs) File "c:\python27\lib\site-packages\_pytest\core.py", line 432, in _docall res = mc.execute() File "c:\python27\lib\site-packages\_pytest\core.py", line 350, in execute res = method(**kwargs) File "c:\python27\lib\site-packages\pytest_xdist-1.8-py2.7.egg\xdist\plugin.py", line 85, in pytest_runtest_protocol reports = forked_run_report(item) File "c:\python27\lib\site-packages\pytest_xdist-1.8-py2.7.egg\xdist\plugin.py", line 105, in forked_run_report ff = py.process.ForkedFunc(runforked) File "c:\python27\lib\site-packages\py\_process\forkedfunc.py", line 30, in __init__ pid = os.fork() AttributeError: 'module' object has no attribute 'fork' -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] [hpk42/pytest] looponfailing mode not working in 2.2.4 (issue #192)
by Alex Greif Sept. 27, 2012

Sept. 27, 2012

--- you can reply above this line --- New issue 192: looponfailing mode not working in 2.2.4 https://bitbucket.org/hpk42/pytest/issue/192/looponfailing-mode-not-working… Alex Greif: Hi, The documented feature in the 2.2.4 docs does not work. $ py.test -f returns: py.test: error: no such option: -f -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] RFC for (hopefully) final commments on pytest-2.3 API
by holger krekel Sept. 25, 2012

Sept. 25, 2012

Hi Brianna, Floris, Carl, Ronny, all, first, let me thank for all the useful feedback you already provided. I am back trying to finalize the next pytest release -- FYI trunk is actually fully functional and implements all previously discussed features. However, I am still pondering Brianna's feedback (that that she found it surprising that there is a @pytest.setup but no teardown) and a few other little naming and protocol issues. If you find some time to state your opinion on one or another issue i'd very much appreciate it: - rename @pytest.setup to @pytest.fixture and the docs would talk about fixture instead of setup functions. (See http://pytest.org/dev/setup.html for the current docs) This would induce less of a question about @pytest.teardown?! - rename @pytest.factory to @pytest.funcarg - because with pytest-trunk it's already the case that the former pytest_funcarg__NAME is just a shortcut - there is no internal distinction anymore if you use the decorator or the prefix or both. Removing the "pytest_funcarg__" prefix and using a @pytest.funcarg(...) declaration looks naturally related?! - introduce a "resource-centric" convenience protocol for fixtures and funcarg factories. It would be used if you decorate a class instead of a function and would lead to the calling of (optional) setup/teardown methods. Here is an example: # content of test_module.py import pytest @pytest.funcarg class db: def setup(self, funcarg1, funcarg2): # called during the setup phase of each test using the "db" # funcarg. this setup function will be called multiple # times in case db.params is defined def teardown(self): # called during the teardown phase of a test which # previously saw a successful db.setup() call - moreover, there could optionally be a class-method "configure" which is called ahead of any setup() and would allow to dynamically compute the scope and params attribute and influence them e. g. from command line options:: @pytest.funcarg class db: @classmethod def configure(cls, config): scope = config.option.scope params = ... ... Dynamic scoping/parametrization is used today if you want to have broadly-scoped less-parametrized resources during development but use more function-scope more-parametrized resources during CI runs. - the same class convenience protocol would work for fixtures: import pytest @pytest.fixture class transact: def setup(self, db): db.begin() self.db = db def teardown(self): self.db.commit() best, holger

3 2

[py-dev] Inspecting requested funcargs
by Floris Bruynooghe Sept. 24, 2012

Sept. 24, 2012

Hi Holger, The new api tried to make it possible to know in advance which funcargs are required for a test function which is a very nice thing to have. However I'm not sure how to get to the full list: @pytest.factory() def arg0(): pass @pytest.factory() def arg1(arg0): pass @pytest.setup() def setup(request): print request.node.funcargnames def test_foo(arg1): pass When executing this with py.test -s this only prints ['arg1'] and I have no idea how to find out that arg0 has also been created/requested. Is there a way to know all the requested funcargs? Floris

2 1

[py-dev] Ordering of setup and funcargs
by Floris Bruynooghe Sept. 24, 2012

Sept. 24, 2012

Hello, As I understand it the order of setup functions being called is: pytest_runtest_setup funcarg resources @setup marked functions And if you mark pytest_runtest_setup with trylast it will be moved down to the bottom. But it is impossible to get a @setup marked function to be called before the funcarg resources are called. This means that in order to be able to influence what is possible inside funcargs [0] you still need to use pytest_runtest_setup. I have no particular opinion on this (yet) but was surprised about this so thought I'd point it out since it still forces plugin writers to use pytest_runtest_setup in some cases. [0] In my case monkeypatch django so you can't get access to it's database using all of django's global state. Regards, Floris

2 1

[py-dev] [hpk42/pytest] Support for unittests TestCase.runTest syntax (issue #191)
by Anonymous Sept. 22, 2012

Sept. 22, 2012

--- you can reply above this line --- New issue 191: Support for unittests TestCase.runTest syntax https://bitbucket.org/hpk42/pytest/issue/191/support-for-unittests-testcase… Anonymous: I'm currently maintaining a collection of unittest.TestCases with most of them containing runTest methods. This syntax seems unfortunately to be unsupported by py.test. Subclassing from TestCase and extending this class with some redirect from TestSubclass.test_run to TestSubclass.runTest to provide compatibility, is possible, but can require some rewrites. Monkeypatching of TestCase with such a function within a generated runtests script seems to work, but is also not the prettiest solution. It would really be nice, if this quite usual syntax of unittest would also be supported out of the box. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] [hpk42/pytest] Naming test methods "setup" causes different behavior (issue #190)
by Alex Okrushko Sept. 21, 2012

Sept. 21, 2012

--- you can reply above this line --- New issue 190: Naming test methods "setup" causes different behavior https://bitbucket.org/hpk42/pytest/issue/190/naming-test-methods-setup-caus… Alex Okrushko: depending on the name of the setup-method the behavior is completely different: 1-st scenario: {{{ #!python class TestMyProp(object): @pytest.setup(scope = "class") def stp(self): self.prop = "init" print self.prop def test_prop(self): TestMyProp.prop = "changed" print self.prop def test_prop_again(self): print self.prop }}} OUTPUT: py.test -sq {{{ #!output ============================= test session starts ============================== platform win32 -- Python 2.7.3 -- pytest-2.3.0.dev15 collecting ... collected 2 items my_test.py init changed .changed . =========================== 2 passed in 0.01 seconds =========================== }}} This is the expected result. NOW change the name of the method to "setup": {{{ #!python class TestMyProp(object): @pytest.setup(scope = "class") def setup(self): self.prop = "init" print self.prop def test_prop(self): TestMyProp.prop = "changed" print self.prop def test_prop_again(self): print self.prop }}} and the output becomes: {{{ #!output ============================= test session starts ============================== platform win32 -- Python 2.7.3 -- pytest-2.3.0.dev15 collecting ... collected 2 items my_test.py init init init .init init . =========================== 2 passed in 0.02 seconds =========================== }}} -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0