Mailman 3 August 2012 - pytest-dev

[py-dev] [hpk42/pytest] usage of py.code.Source.deindent sometimes strangely hangs (issue #184)
by Ronny Pfannschmidt Aug. 28, 2012

Aug. 28, 2012

--- you can reply above this line --- New issue 184: usage of py.code.Source.deindent sometimes strangely hangs https://bitbucket.org/hpk42/pytest/issue/184/usage-of-pycodesourcedeindent-… Ronny Pfannschmidt: the effect is rather strange, the orginal deindent hangs, same goes for one replaced with textwrap.dedent however if one interupts and jumps into pdb, then runs the same dedent again, its suddenly fast the effect can be seen on pypy commit 09c187ceba4a by testing ` jit/backend/llgraph/test -k test_jump --fulltrace` -- 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] investigate armin rigos conftest (issue #183)
by Ronny Pfannschmidt Aug. 28, 2012

Aug. 28, 2012

--- you can reply above this line --- New issue 183: investigate armin rigos conftest https://bitbucket.org/hpk42/pytest/issue/183/investigate-armin-rigos-confte… Ronny Pfannschmidt: armin grew his conftest quite some amounts to keep output semilar to what it was in 2007 (pre 2.x) so we should investigate what was better back then wrt output and bring those things back as builtins or plugins -- 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] pytester.inprocess_run ignores passed plugins (issue #182)
by Ronny Pfannschmidt Aug. 28, 2012

Aug. 28, 2012

--- you can reply above this line --- New issue 182: pytester.inprocess_run ignores passed plugins https://bitbucket.org/hpk42/pytest/issue/182/pytesterinprocess_run-ignores-… Ronny Pfannschmidt: -- 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] --pdb does not work when collecting (issue #181)
by arigo Aug. 28, 2012

Aug. 28, 2012

--- you can reply above this line --- New issue 181: --pdb does not work when collecting https://bitbucket.org/hpk42/pytest/issue/181/pdb-does-not-work-when-collect… arigo: "py.test --pdb" ignores the --pdb option for crashes that occur during collect. Try to run "py.test --pdb test_foo.py" with only the line "crash_here" in test_foo.py. -- 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] new resource API documentation comments
by Brianna Laugher Aug. 26, 2012

Aug. 26, 2012

Hi, I just spent some time reading the dev docs so these comments are just based on the docs and not actually using the new API. In general it looks pretty sensible. - being able to have funcargs like funcargs directly is really nice, a lot more obvious than calling request.getfuncargvalue('foo') - why addfinalizer and not teardown? -although I don't really know what cached_setup did, the trinity of defining the scope, setup and teardown methods made sense to me. Now the scope is in a decorator, the setup is implicitly the entire thing that is happening and the teardown seems somewhat awkwardly tacked on. - none of the "addfinalizer" examples take an argument, how would you convert an old-style teardown method to that? e.g. we have a lot of funcargs which do things like return request.cached_setup(setup=setup, teardown=lambda obj: obj.close(), scope='function') - Sometimes things are referred to as "funcargs", sometimes they are referred to as "injected resources". Is there any difference here? The funcarg is the actual function and the injected resource is the instance in a specific test function? I suggest to use the term "funcarg" as much as possible as it is specific and a necessary concept for using pytest with any depth. Some of the following comments are fairly picky so feel free to ignore them. funcargs.txt line 118 - I think in this first incarnation of the smtp funcarg (factory? what to call it now?), it doesn't actually need to take a testcontext, right? line 527 "Parametrizing test functions" - may be worth having a simple example showing a combination using both (test data) parametrization and funcarg parametrization, to emphasise how they are differently useful. Using a database as an example of funcarg parametrization is good, maybe better than values like 1/2. I feel like parametrizing tests (test data) is probably the more common use case and it is a little buried amongst the heavy duty parametrized funcargs. line 598 "Basic ``pytest_generate_tests`` example" - I think this is not a very basic example! I think it is copied from parametrize.txt page, where it might make more sense. Here is what I would consider a basic example. # code def isSquare(n): n = n ** 0.5 return int(n) == n # test file def pytest_generate_tests(metafunc): squares = [1, 4, 9, 16, 25, 36, 49] for n in range(1, 50): expected = n in squares if metafunc.function.__name__ == 'test_isSquare': metafunc.addcall(id=n, funcargs=dict(n=n, expected=expected)) def test_isSquare(n, expected): assert isSquare(n) == expected Well, this is so trivial you might bundle it all into a single test, but it can be useful to have each case genuinely be a separate test. You could also shoe-horn this data into a parametrize decorator I suppose but it is nicer to have more space if your test data is more complicated, to explain it. I am starting to have a feeling that the way my project has been using generate_tests is not the way everyone else uses it. In our conftest.py one of the enterprising developers on the project (who got us all onto py.test initially) put this: def pytest_generate_tests(__multicall__, metafunc): """Supports parametrised tests using generate_ fns. Use multicall to call any other pytest_generate_tests hooks first. If the test_ fn has a generate_ fn then call it with the metafunc to let it parametrise the test. """ __multicall__.execute() name = metafunc.function.__name__.replace('test_', 'generate_') fn = getattr(metafunc.module, name, None) if fn: fn(metafunc) this means I can simplify my example above to: def generate_isSquare(metafunc): squares = [1, 4, 9, 16, 25, 36, 49] for n in range(1, 50): expected = n in squares metafunc.addcall(id=n, funcargs=dict(n=n, expected=expected)) maybe this is a useful pattern for others? or maybe we're doing it wrong, I dunno :) in funcarg_compare.txt line 53 - (in old-style) "4. there is no way how you can make use of funcarg factories in xUnit setup methods." Is there an example of this? I would like to see it! This sounds like a way for people with existing xUnit style test suites to more easily convert to funcarg style. Maybe with all the parametrized test examples it is a good idea to show the verbose output, just to be more explicit about what is being generated. As an aside, there is a comment in example/markers.txt line 144 that "You can use the ``-k`` command line option to only run tests with names matching the given argument". Whether it is an oversight in the functionality or the docs, I have always found that -k also matches against markers (py.test.mark decorators). (Currently using pytest 2.2.3) in setup.txt line 65 'old = tmpdir.chdir()' - it's not really relevant to the example but I don't know what this does, and I couldn't find out, so it's just a bit distracting. thanks as always for providing this great library :) cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

2 3

[py-dev] pytest talk
by Brianna Laugher Aug. 26, 2012

Aug. 26, 2012

Hi, So I gave my talk on pytest at PyCon AU on the weekend :) Thought it might be of interest to folks here. info: http://2012.pycon-au.org/schedule/52/view_talk?day=sunday slides: http://www.slideshare.net/pfctdayelise/funcargs-other-fun-with-pytest code: https://gist.github.com/3386951 video: http://www.youtube.com/watch?v=DTNejE9EraI cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

2 1

[py-dev] [hpk42/pytest] xdist hides errors (issue #180)
by Ralf Schmitt Aug. 22, 2012

Aug. 22, 2012

--- you can reply above this line --- New issue 180: xdist hides errors https://bitbucket.org/hpk42/pytest/issue/180/xdist-hides-errors Ralf Schmitt: when running without xdist I get the following error: $ py.test ======================================= test session starts ======================================= platform linux2 -- Python 2.7.3 -- pytest-2.2.4 collected 0 items / 1 errors ============================================= ERRORS ============================================== _______________________________________ ERROR collecting . ________________________________________ ../ve/local/lib/python2.7/site-packages/py/_path/common.py:315: in visit > for x in Visitor(fil, rec, ignore, bf, sort).gen(self): ../ve/local/lib/python2.7/site-packages/py/_path/common.py:351: in gen > if p.check(dir=1) and (rec is None or rec(p))]) ../ve/local/lib/python2.7/site-packages/_pytest/main.py:484: in _recurse > ihook.pytest_collect_directory(path=path, parent=self) ../ve/local/lib/python2.7/site-packages/_pytest/main.py:140: in call_matching_hooks > plugins = self.config._getmatchingplugins(self.fspath) ../ve/local/lib/python2.7/site-packages/_pytest/config.py:289: in _getmatchingplugins > plugins += self._conftest.getconftestmodules(fspath) ../ve/local/lib/python2.7/site-packages/_pytest/config.py:188: in getconftestmodules > clist.append(self.importconftest(conftestpath)) ../ve/local/lib/python2.7/site-packages/_pytest/config.py:224: in importconftest > self._postimport(mod) ../ve/local/lib/python2.7/site-packages/_pytest/config.py:229: in _postimport > self._onimport(mod) ../ve/local/lib/python2.7/site-packages/_pytest/config.py:278: in _onimportconftest > self.pluginmanager.consider_conftest(conftestmodule) ../ve/local/lib/python2.7/site-packages/_pytest/core.py:179: in consider_conftest > if self.register(conftestmodule, name=conftestmodule.__file__): ../ve/local/lib/python2.7/site-packages/_pytest/core.py:89: in register > self.hook.pytest_plugin_registered(manager=self, plugin=plugin) ../ve/local/lib/python2.7/site-packages/_pytest/core.py:421: in __call__ > return self._docall(methods, kwargs) ../ve/local/lib/python2.7/site-packages/_pytest/core.py:432: in _docall > res = mc.execute() ../ve/local/lib/python2.7/site-packages/_pytest/core.py:350: in execute > res = method(**kwargs) ../ve/local/lib/python2.7/site-packages/_pytest/core.py:231: in pytest_plugin_registered > {'config': self._config}) ../ve/local/lib/python2.7/site-packages/_pytest/core.py:317: in call_plugin > kwargs=kwargs, firstresult=True).execute() ../ve/local/lib/python2.7/site-packages/_pytest/core.py:350: in execute > res = method(**kwargs) easyindex/conftest.py:75: in pytest_configure > build_index() easyindex/conftest.py:55: in build_index > index = EasyIndex.Index(indexname + ".tmp") easyindex/EasyIndex/__init__.py:45: in Index > from EasyIndex.core import Index easyindex/EasyIndex/core.py:10: in <module> > import _pyfilter E ImportError: No module named _ezindex ----------------------------------------- Captured stdout ----------------------------------------- [building initial index in /home/ralf/bbot/easyindex/tmp_dummy_test_index... ===================================== 1 error in 0.08 seconds ===================================== Running with py.test -n6 gives: $ py.test -n6 ======================================= test session starts ======================================= platform linux2 -- Python 2.7.3 -- pytest-2.2.4 gw0 [0] / gw1 [0] / gw2 [0] / gw3 [0] / gw4 [0] / gw5 [0] scheduling tests via LoadScheduling ======================================== in 0.54 seconds ========================================= xdist hides the error in that case! -- 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] errors in factory setup call terminalwriter with bogous args (issue #179)
by Ronny Pfannschmidt Aug. 20, 2012

Aug. 20, 2012

--- you can reply above this line --- New issue 179: errors in factory setup call terminalwriter with bogous args https://bitbucket.org/hpk42/pytest/issue/179/errors-in-factory-setup-call Ronny Pfannschmidt: {{{ ============================= test session starts ============================== platform linux2 -- Python 2.7.3 -- pytest-2.3.0.dev10 plugins: xdist, codecheckers, couchdbkit, cache collecting ... collected 300 items tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE tests/test_checkout.py EEEE tests/test_client.py EEEEE tests/test_metadata.py EEEEEE tests/test_util.py E tests/test_vc_script.py E tests/remote/test_remote.py EE tests/remote/test_remote_object.py EE tests/repository/test_commit_builder.py E tests/repository/test_creation.py EE tests/repository/test_find.py E tests/repository/test_history.py EEEEE tests/repository/test_history_diff.py E tests/repository/test_renames.py Ex tests/repository/test_repopath.py EE tests/repository/test_simple_renames.py x tests/workdir/test_common.py EEEEEEEEEEE tests/workdir/test_stated_path.py EEE ==================================== ERRORS ==================================== ___________ ERROR at setup of test_checkout_local[direct-subversion] ___________ def pytest_funcarg__repo(request, mgr): LookupError: no factory found for argument 'mgr' available funcargs: pytestconfig, couchdb, couchdb_server, recwarn, spec, repo, wd, monkeypatch, vcs, capfd, capsys, tmpdir, backend use 'py.test --funcargs [testpath]' for help on them. /home/ronny/Projects/pissoff/anyvc/tests/conftest.py:105 ____________ ERROR at setup of test_clone_local[direct-subversion] _____________ def pytest_funcarg__wd(request, mgr): LookupError: no factory found for argument 'mgr' available funcargs: pytestconfig, couchdb, couchdb_server, recwarn, spec, repo, wd, monkeypatch, vcs, capfd, capsys, tmpdir, backend use 'py.test --funcargs [testpath]' for help on them. /home/ronny/Projects/pissoff/anyvc/tests/conftest.py:111 ____________ ERROR at setup of test_clone_remote[direct-subversion] ____________ @py.test.mark.feature('wd:heavy') def test_clone_remote(mgr): LookupError: no factory found for argument 'mgr' available funcargs: pytestconfig, couchdb, couchdb_server, recwarn, spec, repo, wd, monkeypatch, vcs, capfd, capsys, tmpdir, backend use 'py.test --funcargs [testpath]' for help on them. /home/ronny/Projects/pissoff/anyvc/tests/test_checkout.py:37 __________ ERROR at setup of test_checkout_remote[direct-subversion] ___________ @pytest.factory(scope='session') def backend(request, vcs, spec): LookupError: no factory found for argument 'request' available funcargs: pytestconfig, couchdb, couchdb_server, recwarn, spec, repo, wd, monkeypatch, vcs, capfd, capsys, tmpdir, backend use 'py.test --funcargs [testpath]' for help on them. /home/ronny/Projects/pissoff/anyvc/tests/conftest.py:72 ________ ERROR at setup of test_output_state[direct-subversion-deleted] ________ <_pytest.python.SetupCall instance at 0x14253f8>Traceback (most recent call last): File "/home/ronny/.local/virtualenvs/tools/bin/py.test", line 9, in <module> load_entry_point('pytest==2.3.0.dev10', 'console_scripts', 'py.test')() File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 470, in main exitstatus = config.hook.pytest_cmdline_main(config=config) File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 422, in __call__ return self._docall(methods, kwargs) File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 433, in _docall res = mc.execute() File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 351, in execute res = method(**kwargs) File "/home/ronny/Projects/codespeak/pytest/_pytest/main.py", line 103, in pytest_cmdline_main return wrap_session(config, _main) File "/home/ronny/Projects/codespeak/pytest/_pytest/main.py", line 95, in wrap_session exitstatus=session.exitstatus or (session._testsfailed and 1)) File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 422, in __call__ return self._docall(methods, kwargs) File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 433, in _docall res = mc.execute() File "/home/ronny/Projects/codespeak/pytest/_pytest/core.py", line 351, in execute res = method(**kwargs) File "/home/ronny/Projects/codespeak/pytest/_pytest/terminal.py", line 332, in pytest_sessionfinish self.summary_errors() File "/home/ronny/Projects/codespeak/pytest/_pytest/terminal.py", line 430, in summary_errors self._outrep_summary(rep) File "/home/ronny/Projects/codespeak/pytest/_pytest/terminal.py", line 433, in _outrep_summary rep.toterminal(self._tw) File "/home/ronny/Projects/codespeak/pytest/_pytest/runner.py", line 155, in toterminal longrepr.toterminal(out) File "/home/ronny/Projects/codespeak/pytest/_pytest/python.py", line 1215, in toterminal tw.line(line) File "/home/ronny/Projects/codespeak/py/py/_io/terminalwriter.py", line 185, in line self._checkfill(s) File "/home/ronny/Projects/codespeak/py/py/_io/terminalwriter.py", line 197, in _checkfill diff2last = self._lastlen - len(line) AttributeError: SetupCall instance has no attribute '__len__' }}} -- 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] stdout and stderr double-encoded in junitxml (issue #178)
by Jason R. Coombs Aug. 15, 2012

Aug. 15, 2012

--- you can reply above this line --- New issue 178: stdout and stderr double-encoded in junitxml https://bitbucket.org/hpk42/pytest/issue/178/stdout-and-stderr-double-encod… Jason R. Coombs: I'm finding that the junit XML generated by pytest 2.2.4 gets double-encoded output. For example, here's a snippet from one run: {{{ <failure>... Error in parsing gryphon/models/qsl.py:63: QSLError</failure><system-err>Message 1 {&apos;exception&apos;: [&apos;ParseError: Both inline and named res ponse lists were used for question lookahead\n&apos;], &apos;message&apos;: [&apos;ParseError: Both inline and named respo nse lists were used for question lookahead\n&apos;], &apos;status&apos;: 500, ... }}} The stderr stream for that looks something like: {{{ Message 1 {'exception': ['ParseError: Both inline and named response lists were used for question lookahead\n'], 'message': ['ParseError: Both inline and named response lists wer eused for the queston lookahead\n'], 'status': 500, }}} Notice that the tickmarks are being escaped for XML (to ') and then again the ampersand is getting escaped to &apos;. -- 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] New resource API feedback
by Floris Bruynooghe Aug. 15, 2012

Aug. 15, 2012

Hello Holger, I've started experimenting a bit more with the new resource api in pytest-django, I haven't got very far yet but do have already some feedback and questions. Firstly my main issue, I don't know how to inspect the marks on the function/item in a function-scoped setup. Looking at the code the only thing I could find was TestContext._resource.keywords and TestContext._resource.applymarker(). The latter which has an explicit comment saying it is unavailable on purpose. The former almost exposed as TestContext.keywords but commented out. So how do you use markers? This should probably be documented as well. Secondly the docs should probably show how to do teardown in an @setup function. I think it would be nice to show an example of scope and teardown before going into the global resource example. Related to this TestContext.addfinalizer() is not documented in the TestContext API docs. Probably because autodoc doesn't pick it up. Maybe simply merging TestContextRequest into TestContext is enough? TestContextSetup would not need any changes to keep it's behaviour in that case. Next something I have mentioned before, marking a pytest_funcarg__foo function with @factory seems to sill give an incomprehensible error. Personally I think it should be possible and "consume" the funcarg just like @setup consumes e.g. setup_module(), but if I'm alone in that a clearer error would be good improvement. Another thing which surprised me was that @pytest.setup() needs to be called in order to have any effect. Not calling the decorator will simply ignore the setup function, I expected it to treat it as a function-scoped setup. Regards, Floris

2 1