From issues-reply at bitbucket.org Thu Jan 1 16:35:53 2015 From: issues-reply at bitbucket.org (Jason R. Coombs) Date: Thu, 01 Jan 2015 15:35:53 -0000 Subject: [Pytest-commit] Issue #651: test fails in ntpath.py when LocalPath has no len (hpk42/pytest) Message-ID: <20150101153553.30988.31794@app01.ash-private.bitbucket.org> New issue 651: test fails in ntpath.py when LocalPath has no len https://bitbucket.org/hpk42/pytest/issue/651/test-fails-in-ntpathpy-when-localpath-has Jason R. Coombs: Consider this simple test: ``` def test_simple(tmpdir): import os os.path.join(tmpdir, 'foo') ``` Invoke that test on Windows in pytest 2.6.4, and you'll get a failure: ``` ============================= test session starts ============================= platform win32 -- Python 3.4.2 -- py-1.4.26 -- pytest-2.6.4 collected 1 items test_join.py F ================================== FAILURES =================================== _________________________________ test_simple _________________________________ tmpdir = local('C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-19\\test_simple0') def test_simple(tmpdir): import os > os.path.join(tmpdir, 'foo') test_join.py:3: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ c:\python\lib\ntpath.py:108: in join result_drive, result_path = splitdrive(path) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ p = local('C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-19\\test_simple0') def splitdrive(p): """Split a pathname into drive/UNC sharepoint and relative path specifiers. Returns a 2-tuple (drive_or_unc, path); either part may be empty. If you assign result = splitdrive(p) It is always true that: result[0] + result[1] == p If the path contained a drive letter, drive_or_unc will contain everything up to and including the colon. e.g. splitdrive("c:/dir") returns ("c:", "/dir") If the path contained a UNC path, the drive_or_unc will contain the host name and share up to but not including the fourth directory separator character. e.g. splitdrive("//host/computer/dir") returns ("//host/computer", "/dir") Paths cannot contain both a drive letter and a UNC path. """ empty = _get_empty(p) > if len(p) > 1: E TypeError: object of type 'LocalPath' has no len() c:\python\lib\ntpath.py:159: TypeError ========================== 1 failed in 0.07 seconds =========================== ``` Should LocalPath support join operations or should the tester expect to convert the LocalPath to a `str` before invoking join? Probably the preferred usage is to use the `.join()` method on LocalPath, but that's less obvious. From issues-reply at bitbucket.org Fri Jan 2 19:06:54 2015 From: issues-reply at bitbucket.org (Olga Botvinnik) Date: Fri, 02 Jan 2015 18:06:54 -0000 Subject: [Pytest-commit] Issue #652: Specify fixture parameter values in parameterize decorator (hpk42/pytest) Message-ID: <20150102180654.488.57724@app02.ash-private.bitbucket.org> New issue 652: Specify fixture parameter values in parameterize decorator https://bitbucket.org/hpk42/pytest/issue/652/specify-fixture-parameter-values-in Olga Botvinnik: I'm running py.test 2.6.4 and would like to run all parameterizations of a fixture in some tests, but not in others, as described in [this](http://stackoverflow.com/questions/27735413/use-only-certain-fixture-parameterizations-in-different-tests-in-pytest) StackOverflow question. In the MVC-like structure I have, the Model is extensively tested with all parameterizations, but the Controller doesn't need all parameterizations, and some of them are redundant at that level, so I'd like to minimize the number of tests. Essentially, I have a fixture called `n_groups` which parameterizes to `2` and `3`, and then I build several levels of fixtures on top of it to finally create a `metadata_data` fixture: ``` #!python # Contents of conftest.py @pytest.fixture(scope='module', params=[2, ids=['2_groups', '3_groups']) def n_groups(request): """Number of phenotype groups. For testing that functions work when there's only 2 groups """ return request.param @pytest.fixture(scope='module') def groups(n_groups): """Phenotype group names""" return ['group{}'.format(i + 1) for i in np.arange(n_groups)] @pytest.fixture(scope='module') def groupby(groups, samples): return dict((sample, np.random.choice(groups)) for sample in samples) @pytest.fixture(scope='module') def metadata_data(groupby, outliers, pooled, samples, n_samples, metadata_phenotype_col): df = pd.DataFrame(index=samples) if outliers is not None: df['outlier'] = df.index.isin(outliers) if pooled is not None: df['pooled'] = df.index.isin(pooled) df[metadata_phenotype_col] = groupby df['subset1'] = np.random.choice([True, False], size=n_samples) return df ``` What I would like to be able to do is, for certain tests, specify the `n_groups` parameterization through either the value or the ID, like this: ``` #!python # Contents of test_model.py class TestModel(object): def test__init(metadata_data, ...): ... @pytest.mark.parameterize(n_groups=3) def test_plot(metadata_data, ...); ... ``` ``` #!python # Contents of test_controller.py class TestController(object): @pytest.mark.parameterize(n_groups=3) def test__init(metadata_data, ...): ... ``` It seems this is not possible given the current structure of `pytest`. Are there plans to add such a feature in the future? Thank you for creating this excellent package! It has been really great to generate tons of test when just writing one function. From issues-reply at bitbucket.org Fri Jan 2 20:11:14 2015 From: issues-reply at bitbucket.org (Alex Gaynor) Date: Fri, 02 Jan 2015 19:11:14 -0000 Subject: [Pytest-commit] Issue #653: Add a version of deprecated_call which is a context manager (hpk42/pytest) Message-ID: <20150102191114.14752.59402@app04.ash-private.bitbucket.org> New issue 653: Add a version of deprecated_call which is a context manager https://bitbucket.org/hpk42/pytest/issue/653/add-a-version-of-deprecated_call-which-is Alex Gaynor: This would be more convienent for deprecating things like "accessing an attribute" From issues-reply at bitbucket.org Wed Jan 7 12:09:09 2015 From: issues-reply at bitbucket.org (Sorin Sbarnea) Date: Wed, 07 Jan 2015 11:09:09 -0000 Subject: [Pytest-commit] Issue #654: add pass rate option to pytest (hpk42/pytest) Message-ID: <20150107110909.32038.47802@app05.ash-private.bitbucket.org> New issue 654: add pass rate option to pytest https://bitbucket.org/hpk42/pytest/issue/654/add-pass-rate-option-to-pytest Sorin Sbarnea: When you are doing testing at a big scale, and more than just unittesting, like integration testing you will definitely end-up having test that are broken for a long time, tests that to fail almost randomly (flapping) and you will probably never be able to obtain a 100% pass rate. This means that pytest will always fail and you will not be able to pass this stage. As a side effect the development team will give less importance to this as it always RED. If we would have a pass rate, this would enable to make the result as a success even if we have some failures. This would allow you to start CI process with a low pass rate and to slowly increase it over time. It seems that currently pytest does not allow this, or I just don't know how to obtain this behaviour. From issues-reply at bitbucket.org Wed Jan 7 16:46:20 2015 From: issues-reply at bitbucket.org (Tres Seaver) Date: Wed, 07 Jan 2015 15:46:20 -0000 Subject: [Pytest-commit] Issue #207: eventlet 0.16 breaks detox (hpk42/tox) Message-ID: <20150107154620.22363.54066@app05.ash-private.bitbucket.org> New issue 207: eventlet 0.16 breaks detox https://bitbucket.org/hpk42/tox/issue/207/eventlet-016-breaks-detox Tres Seaver: After updating to eventlet 0.16: ``` #!sh $ detox --help Traceback (most recent call last): File "/home/tseaver/bin/detox", line 9, in load_entry_point('detox==0.9.3', 'console_scripts', 'detox')() File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 474, in load_entry_point File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2569, in load_entry_point File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2260, in load File "/opt/Python-2.7.9/lib/python2.7/site-packages/detox-0.9.3-py2.7.egg/detox/main.py", line 5, in from detox.proc import Detox File "/opt/Python-2.7.9/lib/python2.7/site-packages/detox-0.9.3-py2.7.egg/detox/proc.py", line 6, in from eventlet.processes import Process, DeadProcess ImportError: No module named processes ``` detox works fine with 0.15. From commits-noreply at bitbucket.org Fri Jan 9 10:06:56 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Fri, 09 Jan 2015 09:06:56 -0000 Subject: [Pytest-commit] commit/pytest: James Tatum: Cleaning up the docstrings in monkeypatch.py Message-ID: <20150109090656.7164.22542@app12.ash-private.bitbucket.org> 1 new commit in pytest: https://bitbucket.org/hpk42/pytest/commits/f6f70a7ff3eb/ Changeset: f6f70a7ff3eb User: James Tatum Date: 2015-01-09 01:15:22+00:00 Summary: Cleaning up the docstrings in monkeypatch.py Affected #: 1 file diff -r d91265465608bd3777ab0c882e5d68335d7472dd -r f6f70a7ff3eb79863eba18a6a51b17aafe51c8d7 _pytest/monkeypatch.py --- a/_pytest/monkeypatch.py +++ b/_pytest/monkeypatch.py @@ -66,14 +66,14 @@ notset = Notset() class monkeypatch: - """ object keeping a record of setattr/item/env/syspath changes. """ + """ Object keeping a record of setattr/item/env/syspath changes. """ def __init__(self): self._setattr = [] self._setitem = [] self._cwd = None def setattr(self, target, name, value=notset, raising=True): - """ set attribute value on target, memorizing the old value. + """ Set attribute value on target, memorizing the old value. By default raise AttributeError if the attribute did not exist. For convenience you can specify a string as ``target`` which @@ -108,15 +108,15 @@ setattr(target, name, value) def delattr(self, target, name=notset, raising=True): - """ delete attribute ``name`` from ``target``, by default raise + """ Delete attribute ``name`` from ``target``, by default raise AttributeError it the attribute did not previously exist. If no ``name`` is specified and ``target`` is a string it will be interpreted as a dotted import path with the last part being the attribute name. - If raising is set to false, the attribute is allowed to not - pre-exist. + If ``raising`` is set to False, no exception will be raised if the + attribute is missing. """ __tracebackhide__ = True if name is notset: @@ -135,12 +135,16 @@ delattr(target, name) def setitem(self, dic, name, value): - """ set dictionary entry ``name`` to value. """ + """ Set dictionary entry ``name`` to value. """ self._setitem.insert(0, (dic, name, dic.get(name, notset))) dic[name] = value def delitem(self, dic, name, raising=True): - """ delete ``name`` from dict, raise KeyError if it doesn't exist.""" + """ Delete ``name`` from dict. Raise KeyError if it doesn't exist. + + If ``raising`` is set to False, no exception will be raised if the + key is missing. + """ if name not in dic: if raising: raise KeyError(name) @@ -149,7 +153,7 @@ del dic[name] def setenv(self, name, value, prepend=None): - """ set environment variable ``name`` to ``value``. if ``prepend`` + """ Set environment variable ``name`` to ``value``. If ``prepend`` is a character, read the current environment variable value and prepend the ``value`` adjoined with the ``prepend`` character.""" value = str(value) @@ -158,17 +162,22 @@ self.setitem(os.environ, name, value) def delenv(self, name, raising=True): - """ delete ``name`` from environment, raise KeyError it not exists.""" + """ Delete ``name`` from the environment. Raise KeyError it does not + exist. + + If ``raising`` is set to False, no exception will be raised if the + environment variable is missing. + """ self.delitem(os.environ, name, raising=raising) def syspath_prepend(self, path): - """ prepend ``path`` to ``sys.path`` list of import locations. """ + """ Prepend ``path`` to ``sys.path`` list of import locations. """ if not hasattr(self, '_savesyspath'): self._savesyspath = sys.path[:] sys.path.insert(0, str(path)) def chdir(self, path): - """ change the current working directory to the specified path + """ Change the current working directory to the specified path path can be a string or a py.path.local object """ if self._cwd is None: @@ -179,9 +188,9 @@ os.chdir(path) def undo(self): - """ undo previous changes. This call consumes the - undo stack. Calling it a second time has no effect unless - you do more monkeypatching after the undo call.""" + """ Undo previous changes. This call consumes the + undo stack. Calling it a second time has no effect unless + you do more monkeypatching after the undo call.""" for obj, name, value in self._setattr: if value is not notset: setattr(obj, name, value) Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From issues-reply at bitbucket.org Fri Jan 9 19:34:09 2015 From: issues-reply at bitbucket.org (Ronny Pfannschmidt) Date: Fri, 09 Jan 2015 18:34:09 -0000 Subject: [Pytest-commit] Issue #655: sys.excinfo leaks into fixtures on python3 (hpk42/pytest) Message-ID: <20150109183409.13732.4444@app04.ash-private.bitbucket.org> New issue 655: sys.excinfo leaks into fixtures on python3 https://bitbucket.org/hpk42/pytest/issue/655/sysexcinfo-leaks-into-fixtures-on-python3 Ronny Pfannschmidt: ``` import sys import pytest @pytest.fixture def leak(): #fails assert sys.exc_info() == (None, None, None) def test_leak(leak): assert sys.exc_info() == (None, None, None) ``` From commits-noreply at bitbucket.org Fri Jan 9 19:59:14 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Fri, 09 Jan 2015 18:59:14 -0000 Subject: [Pytest-commit] commit/pytest: RonnyPfannschmidt: fix issue 655: crude workarounds around python2/3 exception leaks Message-ID: <20150109185914.31273.73721@app05.ash-private.bitbucket.org> 1 new commit in pytest: https://bitbucket.org/hpk42/pytest/commits/2cec98e0d7cb/ Changeset: 2cec98e0d7cb User: RonnyPfannschmidt Date: 2015-01-09 18:55:49+00:00 Summary: fix issue 655: crude workarounds around python2/3 exception leaks Affected #: 3 files diff -r f6f70a7ff3eb79863eba18a6a51b17aafe51c8d7 -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 CHANGELOG --- a/CHANGELOG +++ b/CHANGELOG @@ -1,6 +1,9 @@ 2.7.0.dev (compared to 2.6.4) ----------------------------- +- fix issue655: work around different ways that cause python2/3 + to leak sys.exc_info into fixtures/tests causing failures in 3rd party code + - fix issue615: assertion re-writing did not correctly escape % signs when formatting boolean operations, which tripped over mixing booleans with modulo operators. Thanks to Tom Viner for the report, @@ -14,7 +17,7 @@ which want to wrap the execution of certain hooks for their purposes. This supersedes the undocumented ``__multicall__`` protocol which pytest itself and some external plugins use. Note that pytest-2.8 - is scheduled to drop supporting the old ``__multicall__`` + is scheduled to drop supporting the old ``__multicall__`` and only support the hookwrapper protocol. - use hookwrapper mechanism in builtin pytest plugins. diff -r f6f70a7ff3eb79863eba18a6a51b17aafe51c8d7 -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 _pytest/python.py --- a/_pytest/python.py +++ b/_pytest/python.py @@ -15,6 +15,8 @@ isfunction = inspect.isfunction isclass = inspect.isclass callable = py.builtin.callable +# used to work around a python2 exception info leak +exc_clear = getattr(sys, 'exc_clear', lambda: None) def getfslineno(obj): # xxx let decorators etc specify a sane ordering @@ -1389,10 +1391,12 @@ cached_result = (self, [0], None) return PseudoFixtureDef raise - result = self._getfuncargvalue(fixturedef) - self._funcargs[argname] = result - self._fixturedefs[argname] = fixturedef - return fixturedef + # remove indent to prevent the python3 exception + # from leaking into the call + result = self._getfuncargvalue(fixturedef) + self._funcargs[argname] = result + self._fixturedefs[argname] = fixturedef + return fixturedef def _get_fixturestack(self): current = self @@ -1439,6 +1443,9 @@ (scope, argname, self.scope, "\n".join(lines)))) __tracebackhide__ = False + # clear sys.exc_info before invoking the fixture (python bug?) + # if its not explicitly cleared it will leak into the call + exc_clear() try: # call the fixture function val = fixturedef.execute(request=subrequest) diff -r f6f70a7ff3eb79863eba18a6a51b17aafe51c8d7 -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 testing/python/fixture.py --- a/testing/python/fixture.py +++ b/testing/python/fixture.py @@ -261,6 +261,29 @@ ]) assert "INTERNAL" not in result.stdout.str() + def test_fixture_excinfo_leak(self, testdir): + # on python2 sys.excinfo would leak into fixture executions + testdir.makepyfile(""" + import sys + import traceback + import pytest + + @pytest.fixture + def leak(): + if sys.exc_info()[0]: # python3 bug :) + traceback.print_exc() + #fails + assert sys.exc_info() == (None, None, None) + + def test_leak(leak): + if sys.exc_info()[0]: # python3 bug :) + traceback.print_exc() + assert sys.exc_info() == (None, None, None) + """) + result = testdir.runpytest() + assert result.ret == 0 + + class TestRequestBasic: def test_request_attributes(self, testdir): item = testdir.getitem(""" Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From issues-reply at bitbucket.org Sat Jan 10 16:49:37 2015 From: issues-reply at bitbucket.org (Eli Collins) Date: Sat, 10 Jan 2015 15:49:37 -0000 Subject: [Pytest-commit] Issue #208: No support for the posargs substitution type (hpk42/tox) Message-ID: <20150110154937.9658.71989@app01.ash-private.bitbucket.org> New issue 208: No support for the posargs substitution type https://bitbucket.org/hpk42/tox/issue/208/no-support-for-the-posargs-substitution Eli Collins: It's quite likely I'm misusing the tox config format, but I've got a rather lengthy tox.ini, with a lot of redundant commands, and wanted to do the following: ``` [testenv:someenv] commands = {posargs:preset-for-some-env} [testenv:someenv2] commands = {[testenv:someenv]commands} [testenv:someenv3] commands = {[testenv:someenv]commands} ``` ... but as of Tox 1.8.1, I get "ConfigError: No support for the posargs substitution type", and have to explicitly duplicate the posargs line for someenv2 and someenv3. From issues-reply at bitbucket.org Tue Jan 13 10:06:46 2015 From: issues-reply at bitbucket.org (thiefmaster) Date: Tue, 13 Jan 2015 09:06:46 -0000 Subject: [Pytest-commit] Issue #656: Better Unicode handling in ID generation (hpk42/pytest) Message-ID: <20150113090646.25976.61600@app11.ash-private.bitbucket.org> New issue 656: Better Unicode handling in ID generation https://bitbucket.org/hpk42/pytest/issue/656/better-unicode-handling-in-id-generation thiefmaster: `some::test[foo-bar]` is much nicer than `some::test[a0-b0]` Any non-ascii characters could be simply skipped or replaced with an underscore (or even transliterated). I think it would also make perfect sense to replace whitespace with underscores. From issues-reply at bitbucket.org Wed Jan 14 09:33:15 2015 From: issues-reply at bitbucket.org (David MacIver) Date: Wed, 14 Jan 2015 08:33:15 -0000 Subject: [Pytest-commit] Issue #657: Errors in teardown_module erroneously attached to last executed test (hpk42/pytest) Message-ID: <20150114083315.9925.47347@app14.ash-private.bitbucket.org> New issue 657: Errors in teardown_module erroneously attached to last executed test https://bitbucket.org/hpk42/pytest/issue/657/errors-in-teardown_module-erroneously David MacIver: Consider a test suite like the following: ``` #!python def teardown_module(module): assert False def test_stuff(): pass def test_things(): pass ``` The result is: ``` collected 2 items test_module_teardown.py ..E =================================================== ERRORS =================================================== ______________________________________ ERROR at teardown of test_things ______________________________________ Traceback (most recent call last): File "/home/david/projects/hypothesis/test_module_teardown.py", line 2, in teardown_module assert False AssertionError: assert False ``` In particular the "ERROR at teardown of test_things" bit is weird. It's not a big deal, but it would be better if this didn't get attached to the test which just happens to have run last but was instead marked as belonging to the module. From issues-reply at bitbucket.org Wed Jan 14 10:36:12 2015 From: issues-reply at bitbucket.org (Torsten Landschoff) Date: Wed, 14 Jan 2015 09:36:12 -0000 Subject: [Pytest-commit] Issue #658: Handling of SystemExit if different pid (after os.fork) (hpk42/pytest) Message-ID: <20150114093612.25999.60129@app14.ash-private.bitbucket.org> New issue 658: Handling of SystemExit if different pid (after os.fork) https://bitbucket.org/hpk42/pytest/issue/658/handling-of-systemexit-if-different-pid Torsten Landschoff: Hi *, I am trying to use our self written ForkServer (something like https://hg.python.org/cpython/file/c917ba25c007/Lib/multiprocessing/forkserver.py but for python2) in unit tests with py.test. ## Background ## It turned out that using os._exit in each child process forked by the ForkServer is not a good idea, because each child process assumes to be a real python process with atexit.register working and correct cleanup of global resources. This causes a deviation between Windows and Linux as well, as we use multiprocessing to start child processes on Windows where atexit and friends work fine of course. Now the ForkServer is basically a [zygote process](https://code.google.com/p/chromium/wiki/LinuxZygote) and is started really early in our application setup code. Therefore we can switch to using sys.exit() just fine, nothing will catch the SystemExit exception from unwinding. ## Problem ## Now this change kills a lot of unit tests because the SystemExit exception propagates to py.test when raised from a fork server created inside a unit test. Obviously using sys.exit here is probably not a good idea, because this will run cleanups from a lot of stuff (other tests, pytest itself etc.). So what I would like to do is to wrap each test function and catch SystemExit there. If SystemExit comes from a different process id that the original pid, this should be mapped to os._exit(), otherwise the SystemExit exception should be propagated as usual. I think this would even be the correct course of action in pytest proper. Unfortunately I can not for the life of me figure out how to do this. I tried to implement the hook pytest_runtest_call in my conftest.py but this only causes the an additional execution of item.runtest() instead of replacing the original implementation. ## Example Code ## The attached test in test_fork.py illustrates the problem. Running it I get the following output: ``` (env)torsten at horatio:~/pytest-fork/bug-fork$ py.test -vrsx ============================= test session starts ============================== platform linux2 -- Python 2.7.3 -- py-1.4.26 -- pytest-2.7.0.dev1 -- /home/torsten/pytest-fork/env/bin/python collected 1 items test_fork.py::test_can_test_fork PASSED =========================== 1 passed in 0.01 seconds =========================== =================================== FAILURES =================================== ______________________________ test_can_test_fork ______________________________ @pytest.mark.skipif(not hasattr(os, "fork"), reason="os.fork is missing, I need a real operating system") def test_can_test_fork(): pid = os.fork() if not pid: > sys.exit() E SystemExit test_fork.py:9: SystemExit =========================== 1 failed in 0.02 seconds =========================== (env)torsten at horatio:~/pytest-fork/bug-fork$ ``` What I would have expected is successful termination. ## Attempted patch ## The attachment catch_system_exit.diff contains a patch that fixes the problem for me. Your mileage may vary, applying this everywhere might not be such a good idea. Unfortunately I can not easily replace pytest on all our build machines with a custom build. I'd really like to stay with a released version and add this behaviour via conftest. Hints greatly appreciated. From issues-reply at bitbucket.org Thu Jan 15 13:39:05 2015 From: issues-reply at bitbucket.org (Torsten Landschoff) Date: Thu, 15 Jan 2015 12:39:05 -0000 Subject: [Pytest-commit] Issue #659: Using tmpdir in session scoped fixture changes the fixture to be function scoped (hpk42/pytest) Message-ID: <20150115123905.3085.13770@app08.ash-private.bitbucket.org> New issue 659: Using tmpdir in session scoped fixture changes the fixture to be function scoped https://bitbucket.org/hpk42/pytest/issue/659/using-tmpdir-in-session-scoped-fixture Torsten Landschoff: Running the attached tests gives ``` $ py.test -q --tb=short test_cached_mkdtemp.py .. 2 passed in 0.03 seconds ``` as expected, but doing the same using tmpdir I get ``` $ py.test -q --tb=short test_cached_tmpdir.py .E ==================================== ERRORS ==================================== ______________________ ERROR at setup of test_property_b _______________________ test_cached_tmpdir.py:21: in scenario_prototype return ScenarioPrototype(tmpdir.join("prototype")) test_cached_tmpdir.py:40: in __init__ assert ScenarioPrototype.instantiation_count <= 1 E assert 2 <= 1 E + where 2 = ScenarioPrototype.instantiation_count ------------------------------- Captured stdout -------------------------------- Creating scenario prototype in /tmp/pytest-89/test_property_b0/prototype 1 passed, 1 error in 0.03 seconds ``` Tested with pytest 2.6.4 and pytest 2.5.1. I would have expected both to behave identically. From issues-reply at bitbucket.org Thu Jan 15 14:57:44 2015 From: issues-reply at bitbucket.org (Praveen Shirali) Date: Thu, 15 Jan 2015 13:57:44 -0000 Subject: [Pytest-commit] Issue #660: Module scope fixture runs on function scope (hpk42/pytest) Message-ID: <20150115135744.12266.70934@app09.ash-private.bitbucket.org> New issue 660: Module scope fixture runs on function scope https://bitbucket.org/hpk42/pytest/issue/660/module-scope-fixture-runs-on-function Praveen Shirali: I came across the following situation which I have simplified into the example below. If a `Module Fixture` depends on a `Function Fixture` and a test depends on both, but has `(Function Fixture, Module Fixture)` in its argument order, the `Module Fixture` is reduced to run as a `Function Fixture` Tested on py.test 2.6.4 ``` #!python import pytest class SomeClass(object): pass @pytest.fixture def function_fixture(request): def fin(): print "I am a function finalizer" request.addfinalizer(fin) print "\n" print "I am a function fixture" return SomeClass() @pytest.fixture(scope="module") def module_fixture(request, function_fixture): def fin(): print "I am a module finalizer" request.addfinalizer(fin) print "I am a module fixture" return SomeClass() def test_one(function_fixture, module_fixture): print "Test One" print "Module Fixture: {}".format(module_fixture) def test_two(function_fixture, module_fixture): print "Test Two" print "Module Fixture: {}".format(module_fixture) ``` Output: (-s --verbose) ``` test.py::test_one I am a function fixture I am a module fixture Test One Module Fixture: PASSEDI am a module finalizer I am a function finalizer test.py::test_two I am a function fixture I am a module fixture Test Two Module Fixture: PASSEDI am a module finalizer I am a function finalizer ``` Notice that the Module Fixture code has executed twice and the addresses of the SomeClass instances are different. If `module_fixture` did not depend on `function_fixture`, the `module_fixture` would run only once. Test function calling `(module_fixture, function_fixture)` results in a `ScopeMismatchError`. From issues-reply at bitbucket.org Thu Jan 15 16:56:43 2015 From: issues-reply at bitbucket.org (davidkr) Date: Thu, 15 Jan 2015 15:56:43 -0000 Subject: [Pytest-commit] Issue #661: Automatic grouping of tests by fixture instances broken (hpk42/pytest) Message-ID: <20150115155643.22360.93088@app04.ash-private.bitbucket.org> New issue 661: Automatic grouping of tests by fixture instances broken https://bitbucket.org/hpk42/pytest/issue/661/automatic-grouping-of-tests-by-fixture davidkr: from [Automatic grouping of tests by fixture instances](http://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances) > pytest minimizes the number of active fixtures during test runs. If you have a parametrized > fixture, then all the tests using it will first execute with one instance and then finalizers are > called before the next fixture instance is created. Among other things, this eases testing of > applications which create and use global state. However the grouping doesn't seem to be working in some cases. Below is an example of what I mean. Here's the test code... ``` #!python import pytest @pytest.yield_fixture(scope="session", params=["big mac", "whopper"]) def burger(request): yield request.param @pytest.yield_fixture(scope="session", params=["curlyfries", "regularfries"]) def fries(request): yield request.param def test_burgers(burger): print "test_burgers: {0}".format(burger) def test_combo1(burger, fries): print("test_combo1: {0}{1}".format(burger, fries)) ``` The output from running the tests.. ``` test_grouping.py::test_burgers[big mac] PASSED test_grouping.py::test_combo1[big mac-curlyfries] PASSED test_grouping.py::test_combo1[whopper-curlyfries] PASSED test_grouping.py::test_burgers[whopper] PASSED test_grouping.py::test_combo1[whopper-regularfries] PASSED test_grouping.py::test_combo1[big mac-regularfries] PASSED ``` So the *whopper* instance of the *burger* fixture was created before the *big mac* instance was finalized and all its dependent tests were executed. I ran into this with my own test suite when I change a session-scoped fixture that other fixtures depended on from using the ```@pytest.fixture``` decorator to using ```metafunc.parametrize```. At first I thought it was a bug with using ```metafunc.parametrize``` but when I created a simpler reproduction set of tests I still get the same issue with simply using the decorator. It's more obvious when using metafunc though. For e.g. if I change the above test suite to use metafunc by doing this.. ``` #!python import pytest def pytest_generate_tests(metafunc): if "burger" in metafunc.fixturenames: metafunc.parametrize("burger", argvalues=["big mac", "whopper"]) ``` ..then the order changes yet again, all instances of ```test_burger``` get run first and the output looks like this.... ``` test_grouping_metafunc.py::test_burgers[big mac] PASSED test_grouping_metafunc.py::test_burgers[whopper] PASSED test_grouping_metafunc.py::test_combo1[big mac-curlyfries] PASSED test_grouping_metafunc.py::test_combo1[whopper-curlyfries] PASSED test_grouping_metafunc.py::test_combo1[big mac-regularfries] PASSED test_grouping_metafunc.py::test_combo1[whopper-regularfries] PASSED ``` If grouping was working as documented I'd expect the correct order to be... ``` test_grouping_metafunc.py::test_burgers[big mac] PASSED test_grouping_metafunc.py::test_combo1[big mac-curlyfries] PASSED test_grouping_metafunc.py::test_combo1[big mac-regularfries] PASSED test_grouping_metafunc.py::test_burgers[whopper] PASSED test_grouping_metafunc.py::test_combo1[whopper-curlyfries] PASSED test_grouping_metafunc.py::test_combo1[whopper-regularfries] PASSED ``` I've tried with non-yield fixtures as well and that made no difference. From commits-noreply at bitbucket.org Thu Jan 15 21:22:53 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Thu, 15 Jan 2015 20:22:53 -0000 Subject: [Pytest-commit] commit/pytest: 2 new changesets Message-ID: <20150115202253.7437.3094@app06.ash-private.bitbucket.org> 2 new commits in pytest: https://bitbucket.org/hpk42/pytest/commits/000b5a3962f5/ Changeset: 000b5a3962f5 Branch: okin/only-one-import-on-one-line-if-this-shou-1421239108222 User: okin Date: 2015-01-14 12:38:37+00:00 Summary: Only one import on one line. If this should show good practices, the code should not set a bad example ;) Affected #: 1 file diff -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 -r 000b5a3962f58f7637e935e2b3ba7f2a8c4ce092 doc/en/goodpractises.txt --- a/doc/en/goodpractises.txt +++ b/doc/en/goodpractises.txt @@ -194,7 +194,8 @@ pass def run(self): - import sys,subprocess + import subprocess + import sys errno = subprocess.call([sys.executable, 'runtests.py']) raise SystemExit(errno) https://bitbucket.org/hpk42/pytest/commits/d942d16857f3/ Changeset: d942d16857f3 User: hpk42 Date: 2015-01-15 20:22:49+00:00 Summary: Merged in okin/pytest/okin/only-one-import-on-one-line-if-this-shou-1421239108222 (pull request #238) Only one import on one line. Affected #: 1 file diff -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 -r d942d16857f3fd225d25bc21aa6531449163528c doc/en/goodpractises.txt --- a/doc/en/goodpractises.txt +++ b/doc/en/goodpractises.txt @@ -194,7 +194,8 @@ pass def run(self): - import sys,subprocess + import subprocess + import sys errno = subprocess.call([sys.executable, 'runtests.py']) raise SystemExit(errno) Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From commits-noreply at bitbucket.org Thu Jan 15 21:22:53 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Thu, 15 Jan 2015 20:22:53 -0000 Subject: [Pytest-commit] commit/pytest: hpk42: Merged in okin/pytest/okin/only-one-import-on-one-line-if-this-shou-1421239108222 (pull request #238) Message-ID: <20150115202253.3132.98@app11.ash-private.bitbucket.org> 1 new commit in pytest: https://bitbucket.org/hpk42/pytest/commits/d942d16857f3/ Changeset: d942d16857f3 User: hpk42 Date: 2015-01-15 20:22:49+00:00 Summary: Merged in okin/pytest/okin/only-one-import-on-one-line-if-this-shou-1421239108222 (pull request #238) Only one import on one line. Affected #: 1 file diff -r 2cec98e0d7cb292ed55a2b7482ec6d3c2cff90f9 -r d942d16857f3fd225d25bc21aa6531449163528c doc/en/goodpractises.txt --- a/doc/en/goodpractises.txt +++ b/doc/en/goodpractises.txt @@ -194,7 +194,8 @@ pass def run(self): - import sys,subprocess + import subprocess + import sys errno = subprocess.call([sys.executable, 'runtests.py']) raise SystemExit(errno) Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From issues-reply at bitbucket.org Thu Jan 15 23:37:17 2015 From: issues-reply at bitbucket.org (Boris Rybalkin) Date: Thu, 15 Jan 2015 22:37:17 -0000 Subject: [Pytest-commit] Issue #662: fail on zero tests found (hpk42/pytest) Message-ID: <20150115223717.31504.77528@app06.ash-private.bitbucket.org> New issue 662: fail on zero tests found https://bitbucket.org/hpk42/pytest/issue/662/fail-on-zero-tests-found Boris Rybalkin: Sometimes it is critical to fail when py.test does not find any test. This may happen when you are accidentally running in the wrong directory on the build agent and may lead to the impression that everything is ok. From issues-reply at bitbucket.org Fri Jan 16 11:01:26 2015 From: issues-reply at bitbucket.org (asdfsx) Date: Fri, 16 Jan 2015 10:01:26 -0000 Subject: [Pytest-commit] Issue #209: problem with virtualenv 12.x (hpk42/tox) Message-ID: <20150116100126.26940.59108@app11.ash-private.bitbucket.org> New issue 209: problem with virtualenv 12.x https://bitbucket.org/hpk42/tox/issue/209/problem-with-virtualenv-12x asdfsx: tox cannot work well with virtualenv 12.x cause exceptions like below: Traceback (most recent call last): File "C:\Python27\Scripts\tox-script.py", line 5, in from pkg_resources import load_entry_point File "C:\Python27\lib\site-packages\pkg_resources.py", line 2735, in working_set.require(__requires__) File "C:\Python27\lib\site-packages\pkg_resources.py", line 690, in require needed = self.resolve(parse_requirements(requirements)) File "C:\Python27\lib\site-packages\pkg_resources.py", line 588, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: virtualenv>=1.11.2 From issues-reply at bitbucket.org Fri Jan 16 16:30:42 2015 From: issues-reply at bitbucket.org (Ronny Pfannschmidt) Date: Fri, 16 Jan 2015 15:30:42 -0000 Subject: [Pytest-commit] Issue #210: non-tes automation (hpk42/tox) Message-ID: <20150116153042.16852.69362@app13.ash-private.bitbucket.org> New issue 210: non-tes automation https://bitbucket.org/hpk42/tox/issue/210/non-tes-automation Ronny Pfannschmidt: while restarting to write my blog, i noticed there is no beautiful tooling to setup and use pyhon based dependences for the generators and run them in deveop/publish modes after pondering some i wondered if tox couldnt be a tool for that instead of enforcing the sdist/test steps, i propose adding the ability to completely skip the sdist setup steps, just setting up envs and running commands in them From issues-reply at bitbucket.org Sat Jan 17 19:37:25 2015 From: issues-reply at bitbucket.org (David Szotten) Date: Sat, 17 Jan 2015 18:37:25 -0000 Subject: [Pytest-commit] Issue #663: node ids not unique (hpk42/pytest) Message-ID: <20150117183725.25072.84183@app09.ash-private.bitbucket.org> New issue 663: node ids not unique https://bitbucket.org/hpk42/pytest/issue/663/node-ids-not-unique David Szotten: Not sure if this is expected, but i certainly had the impression that node ids were unique. However, using `parametrize` with e.g. `params = [1, '1']` results in two distinct nodes with the same ids. From commits-noreply at bitbucket.org Mon Jan 19 22:34:47 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Mon, 19 Jan 2015 21:34:47 -0000 Subject: [Pytest-commit] commit/pytest: hpk42: Merged in nicoddemus/pytest/pastebin-xdist (pull request #239) Message-ID: <20150119213447.16405.47982@app04.ash-private.bitbucket.org> 1 new commit in pytest: https://bitbucket.org/hpk42/pytest/commits/fa62c5c63c2f/ Changeset: fa62c5c63c2f User: hpk42 Date: 2015-01-19 21:34:43+00:00 Summary: Merged in nicoddemus/pytest/pastebin-xdist (pull request #239) Using pytest-xdist and --paste=all results in error Affected #: 1 file diff -r d942d16857f3fd225d25bc21aa6531449163528c -r fa62c5c63c2fb5870852676d8d8899b9656214fd _pytest/pastebin.py --- a/_pytest/pastebin.py +++ b/_pytest/pastebin.py @@ -14,13 +14,17 @@ @pytest.mark.trylast def pytest_configure(config): if config.option.pastebin == "all": - config._pastebinfile = tempfile.TemporaryFile('w+') tr = config.pluginmanager.getplugin('terminalreporter') - oldwrite = tr._tw.write - def tee_write(s, **kwargs): - oldwrite(s, **kwargs) - config._pastebinfile.write(str(s)) - tr._tw.write = tee_write + # if no terminal reporter plugin is present, nothing we can do here; + # this can happen when this function executes in a slave node + # when using pytest-xdist, for example + if tr is not None: + config._pastebinfile = tempfile.TemporaryFile('w+') + oldwrite = tr._tw.write + def tee_write(s, **kwargs): + oldwrite(s, **kwargs) + config._pastebinfile.write(str(s)) + tr._tw.write = tee_write def pytest_unconfigure(config): if hasattr(config, '_pastebinfile'): Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From commits-noreply at bitbucket.org Mon Jan 19 22:34:47 2015 From: commits-noreply at bitbucket.org (commits-noreply at bitbucket.org) Date: Mon, 19 Jan 2015 21:34:47 -0000 Subject: [Pytest-commit] commit/pytest: 2 new changesets Message-ID: <20150119213447.19170.89083@app01.ash-private.bitbucket.org> 2 new commits in pytest: https://bitbucket.org/hpk42/pytest/commits/2b5be564845e/ Changeset: 2b5be564845e Branch: pastebin-xdist User: nicoddemus Date: 2015-01-19 21:20:01+00:00 Summary: Attempting to patch terminal only if terminalreporter is available This fixes the flag "--paste=all" when running tests with xdist, as slaves would attempt to patch a non-existing terminal during pytest_configure. Only the master node has a terminalreporter installed. Affected #: 1 file diff -r d942d16857f3fd225d25bc21aa6531449163528c -r 2b5be564845e868700a50c23ebcf89b62fdf38d7 _pytest/pastebin.py --- a/_pytest/pastebin.py +++ b/_pytest/pastebin.py @@ -14,13 +14,17 @@ @pytest.mark.trylast def pytest_configure(config): if config.option.pastebin == "all": - config._pastebinfile = tempfile.TemporaryFile('w+') tr = config.pluginmanager.getplugin('terminalreporter') - oldwrite = tr._tw.write - def tee_write(s, **kwargs): - oldwrite(s, **kwargs) - config._pastebinfile.write(str(s)) - tr._tw.write = tee_write + # if no terminal reporter plugin is present, nothing we can do here; + # this can happen when this function executes in a slave node + # when using pytest-xdist, for example + if tr is not None: + config._pastebinfile = tempfile.TemporaryFile('w+') + oldwrite = tr._tw.write + def tee_write(s, **kwargs): + oldwrite(s, **kwargs) + config._pastebinfile.write(str(s)) + tr._tw.write = tee_write def pytest_unconfigure(config): if hasattr(config, '_pastebinfile'): https://bitbucket.org/hpk42/pytest/commits/fa62c5c63c2f/ Changeset: fa62c5c63c2f User: hpk42 Date: 2015-01-19 21:34:43+00:00 Summary: Merged in nicoddemus/pytest/pastebin-xdist (pull request #239) Using pytest-xdist and --paste=all results in error Affected #: 1 file diff -r d942d16857f3fd225d25bc21aa6531449163528c -r fa62c5c63c2fb5870852676d8d8899b9656214fd _pytest/pastebin.py --- a/_pytest/pastebin.py +++ b/_pytest/pastebin.py @@ -14,13 +14,17 @@ @pytest.mark.trylast def pytest_configure(config): if config.option.pastebin == "all": - config._pastebinfile = tempfile.TemporaryFile('w+') tr = config.pluginmanager.getplugin('terminalreporter') - oldwrite = tr._tw.write - def tee_write(s, **kwargs): - oldwrite(s, **kwargs) - config._pastebinfile.write(str(s)) - tr._tw.write = tee_write + # if no terminal reporter plugin is present, nothing we can do here; + # this can happen when this function executes in a slave node + # when using pytest-xdist, for example + if tr is not None: + config._pastebinfile = tempfile.TemporaryFile('w+') + oldwrite = tr._tw.write + def tee_write(s, **kwargs): + oldwrite(s, **kwargs) + config._pastebinfile.write(str(s)) + tr._tw.write = tee_write def pytest_unconfigure(config): if hasattr(config, '_pastebinfile'): Repository URL: https://bitbucket.org/hpk42/pytest/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. From issues-reply at bitbucket.org Tue Jan 20 15:26:44 2015 From: issues-reply at bitbucket.org (realcr realcr) Date: Tue, 20 Jan 2015 14:26:44 -0000 Subject: [Pytest-commit] Issue #664: Assertions about expected exceptions documentation possible code error (hpk42/pytest) Message-ID: <20150120142644.15830.72556@app02.ash-private.bitbucket.org> New issue 664: Assertions about expected exceptions documentation possible code error https://bitbucket.org/hpk42/pytest/issue/664/assertions-about-expected-exceptions realcr realcr: Hi, I have seen the following piece of code in the documentation at http://pytest.org/latest/assert.html#assert-with-the-assert-statement : def test_recursion_depth(): with pytest.raises(RuntimeError) as excinfo: def f(): f() f() assert 'maximum recursion' in str(excinfo.value) I assume that the assert line should be indented one more level to the right. I might be wrong about it though. From issues-reply at bitbucket.org Thu Jan 22 11:04:24 2015 From: issues-reply at bitbucket.org (mcarans) Date: Thu, 22 Jan 2015 10:04:24 -0000 Subject: [Pytest-commit] Issue #211: Make tox available as a wheel (.whl) (hpk42/tox) Message-ID: <20150122100424.19890.15534@app07.ash-private.bitbucket.org> New issue 211: Make tox available as a wheel (.whl) https://bitbucket.org/hpk42/tox/issue/211/make-tox-available-as-a-wheel-whl mcarans: Please make tox available as a wheel (.whl). tox is not available as a .whl from Pypi (https://pypi.python.org/pypi/devpi/). WinPython supports whl files in its Control Panel as of 3.4.2.4 and 2.7.9.2. Even http://www.lfd.uci.edu/~gohlke/pythonlibs/ which used to contain exe files now contains only whl files. So would be good for tox to be available in this format. Thanks. From issues-reply at bitbucket.org Fri Jan 23 16:37:34 2015 From: issues-reply at bitbucket.org (Daniel Hahler) Date: Fri, 23 Jan 2015 15:37:34 -0000 Subject: [Pytest-commit] Issue #665: pytest.mark.skipif marker does not display / have correct source information (hpk42/pytest) Message-ID: <20150123153734.18449.48805@app12.ash-private.bitbucket.org> New issue 665: pytest.mark.skipif marker does not display / have correct source information https://bitbucket.org/hpk42/pytest/issue/665/pytestmarkskipif-marker-does-not-display Daniel Hahler: When using the pytest.mark.skipif marker, the test summary does not report the location of the marker / test, but where `pytest.skip()` is being called internally: ======================================================================== short test summary info ======================================================================== SKIP [2] /path/to/pytest/_pytest/skipping.py:140: Django < 1.7 doesn't have migrations This is the code that calls it: @pytest.mark.tryfirst def pytest_runtest_setup(item): evalskip = MarkEvaluator(item, 'skipif') if evalskip.istrue(): pytest.skip(evalskip.getexplanation()) item._evalxfail = MarkEvaluator(item, 'xfail') check_xfail_no_run(item) From issues-reply at bitbucket.org Fri Jan 23 17:35:26 2015 From: issues-reply at bitbucket.org (Daniel Hahler) Date: Fri, 23 Jan 2015 16:35:26 -0000 Subject: [Pytest-commit] Issue #666: pytest.mark.skipif on class method uses "reason" from class level pytestmark (hpk42/pytest) Message-ID: <20150123163526.7658.43186@app09.ash-private.bitbucket.org> New issue 666: pytest.mark.skipif on class method uses "reason" from class level pytestmark https://bitbucket.org/hpk42/pytest/issue/666/pytestmarkskipif-on-class-method-uses Daniel Hahler: Given the following test, the reason should be "function level", but is reported as "class level": import pytest class Tests: pytestmark = [ pytest.mark.skipif(False, reason="class level"), ] @pytest.mark.skipif(True, reason="function level") def test_skip_if(): pass % ~v/pytest % py.test test_skipif.py === test session starts === platform linux -- Python 3.4.2 -- py-1.4.26 -- pytest-2.7.0.dev1 collected 1 items test_skipif.py s === short test summary info ============================== SKIP [1] /home/daniel/Vcs/pytest/_pytest/skipping.py:140: class level === 1 skipped in 0.01 seconds ============================ This is related to issue #665. From issues-reply at bitbucket.org Sun Jan 25 23:15:56 2015 From: issues-reply at bitbucket.org (Nils Werner) Date: Sun, 25 Jan 2015 22:15:56 -0000 Subject: [Pytest-commit] Issue #667: Make tests using random numbers more reproducible (hpk42/pytest) Message-ID: <20150125221556.16470.95392@app07.ash-private.bitbucket.org> New issue 667: Make tests using random numbers more reproducible https://bitbucket.org/hpk42/pytest/issue/667/make-tests-using-random-numbers-more Nils Werner: I recently was thinking about what to do to make the use of random numbers more reproducible. Currently, when a test using a random number fails, there is no way of backtracking what random number seed was actually used so that the test can be reproduced. So... 1. While using `tox` I noticed it always sets `PYTHONHASHSEED` itself (to a random value, but printing that value) to ensure people can reproduce tests failing due to anything that has to do with that environment variable 2. While using `pytest-django` I noticed they always set the database back into its initial state and [require the tests to be marked (or have a `db` fixture)](http://pytest-django.readthedocs.org/en/latest/database.html#enabling-database-access) to touch the dabase. This brought me to the idea of controlling the `random` module a bit more to: - Set the seed - to a constant value, or - to a random value, printing that value in case of errors, or - reset the seed after each test, or - Allowing the test to set a seed without affecting other tests For example, currently you can do import pytest import my_module import random def test_something(): assert random.random() > 0.5 Which gives absolutely no information why and in what situations the (rather idiotic) test is failing. Or, when you have two tests import pytest import my_module import random def test_something(): assert random.random() > 0.5 def test_something_else(): assert random.random() > 0.5 The order of execution changes the values each test sees (particularily troubling with `xdist` I guess) ideally, the above code should fail and should be replaced with import pytest import my_module def test_something(random): assert random.random() > 0.5 That way pytest could always prepare `random` to be in the identical state for each tests and remember the seed value and print it, hinting at the fact that there are random numbers at play here. I haven't given too much thought about how to achieve this behaviour (monkeypatching the `random` module I guess) but first wanted to hear what you guys think. From issues-reply at bitbucket.org Mon Jan 26 19:47:25 2015 From: issues-reply at bitbucket.org (tgoodlet) Date: Mon, 26 Jan 2015 18:47:25 -0000 Subject: [Pytest-commit] Issue #668: autouse fixtures break scope rules (hpk42/pytest) Message-ID: <20150126184725.5835.42955@app09.ash-private.bitbucket.org> New issue 668: autouse fixtures break scope rules https://bitbucket.org/hpk42/pytest/issue/668/autouse-fixtures-break-scope-rules tgoodlet: I believe this issue is very similar to [#660](https://bitbucket.org/hpk42/pytest/issue/660/module-scope-fixture-runs-on-function) The problem is easily reproduced. Say you have the following very simple test mod `test_fixture_scopes.py` ``` import pytest @pytest.fixture def func_level(request): return 'blah' @pytest.fixture(scope='session') def sess_level(func_level): return func_level def test_fscopes(sess_level): print sess_level ``` As expected this fixture chain breaks scope rules: ``` $ py.test --tb=short ./test_fixture_scopes ============================================================================================================= test session starts ========================== platform linux2 -- Python 2.7.9 -- py-1.4.26 -- pytest-2.6.4 -- /usr/bin/python2 plugins: interactive, ordering, ipdb collected 1 items test_fixture_scopes.py::test_fscopes ERROR =================================================================================================================== ERRORS ========================== _______________________________________________________________________________________________________ ERROR at setup of test_fscopes ________________________________________________________________________________________________________ /usr/lib/python2.7/site-packages/_pytest/runner.py:139: in __init__ self.result = func() /usr/lib/python2.7/site-packages/_pytest/runner.py:127: in return CallInfo(lambda: ihook(item=item, **kwds), when=when) /usr/lib/python2.7/site-packages/_pytest/main.py:167: in call_matching_hooks return hookmethod.pcall(plugins, **kwargs) /usr/lib/python2.7/site-packages/_pytest/core.py:417: in pcall return self._docall(methods, kwargs) /usr/lib/python2.7/site-packages/_pytest/core.py:424: in _docall res = mc.execute() /usr/lib/python2.7/site-packages/_pytest/core.py:315: in execute res = method(**kwargs) /usr/lib/python2.7/site-packages/_pytest/runner.py:86: in pytest_runtest_setup item.session._setupstate.prepare(item) /usr/lib/python2.7/site-packages/_pytest/runner.py:393: in prepare col.setup() /usr/lib/python2.7/site-packages/_pytest/python.py:1141: in setup fillfixtures(self) /usr/lib/python2.7/site-packages/_pytest/python.py:667: in fillfixtures request._fillfixtures() /usr/lib/python2.7/site-packages/_pytest/python.py:1289: in _fillfixtures item.funcargs[argname] = self.getfuncargvalue(argname) /usr/lib/python2.7/site-packages/_pytest/python.py:1337: in getfuncargvalue return self._get_active_fixturedef(argname).cached_result[0] /usr/lib/python2.7/site-packages/_pytest/python.py:1351: in _get_active_fixturedef result = self._getfuncargvalue(fixturedef) /usr/lib/python2.7/site-packages/_pytest/python.py:1403: in _getfuncargvalue val = fixturedef.execute(request=subrequest) /usr/lib/python2.7/site-packages/_pytest/python.py:1825: in execute fixturedef = request._get_active_fixturedef(argname) /usr/lib/python2.7/site-packages/_pytest/python.py:1351: in _get_active_fixturedef result = self._getfuncargvalue(fixturedef) E ScopeMismatchError: You tried to access the 'function' scoped fixture 'func_level' with a 'session' scoped request object, involved factories E test_fixture_scopes.py:3: def sess_level(func_level) E test_fixture_scopes.py:8: def func_level(request) =========================================================================================================== 1 error in 0.04 seconds ========================== ``` But now add a sibling autouse fixture which consumes `sess_level` to the same file: ```python @pytest.fixture(autouse=True) def always(func_level): print func_level ``` Run again and the scope mismatch error dissappears? ``` $ py.test --tb=short ./test_fixture_scopes ============================================================================================================= test session starts ================================================================= platform linux2 -- Python 2.7.9 -- py-1.4.26 -- pytest-2.6.4 -- /usr/bin/python2 plugins: interactive, ordering, ipdb collected 1 items test_fixture_scopes.py::test_fscopes blah blah PASSED ========================================================================================================== 1 passed in 0.01 seconds ======================== ``` This caused some very unexpected results for me since the scoped `sess_level` will be retriggered for every consuming test once the autouse sibling is added. Since there was no error and I am dealing with a large fixture set, I was unaware that I was breaking scope rules and instead saw odd fixture execution orders. From issues-reply at bitbucket.org Thu Jan 29 08:53:54 2015 From: issues-reply at bitbucket.org (vmalloc) Date: Thu, 29 Jan 2015 07:53:54 -0000 Subject: [Pytest-commit] Issue #669: py.test not running any tests when using -n (xdist) (hpk42/pytest) Message-ID: <20150129075354.13781.30264@app08.ash-private.bitbucket.org> New issue 669: py.test not running any tests when using -n (xdist) https://bitbucket.org/hpk42/pytest/issue/669/pytest-not-running-any-tests-when-using-n vmalloc: When I run py.test without any arguments all my tests are running as expected: ``` $ py.test tests ========================================================= test session starts ========================================================= platform darwin -- Python 2.7.9 -- py-1.4.26 -- pytest-2.6.4 plugins: capturelog, xdist collected 438 items ....... (omitted) =============================================== 435 passed, 3 skipped in 33.90 seconds ================================================ ``` However, when I pass `-n 4`, nothing gets actually run: ``` in/py.test -n 4 ========================================================= test session starts ========================================================= platform darwin -- Python 2.7.9 -- py-1.4.26 -- pytest-2.6.4 plugins: capturelog, xdist gw0 [439] / gw1 [439] / gw2 [439] / gw3 [439] scheduling tests via LoadScheduling ========================================================== in 3.03 seconds =========================================================== ``` From issues-reply at bitbucket.org Thu Jan 29 17:30:19 2015 From: issues-reply at bitbucket.org (Anatoly Bubenkov) Date: Thu, 29 Jan 2015 16:30:19 -0000 Subject: [Pytest-commit] Issue #670: parallelize rsync in xdist (hpk42/pytest) Message-ID: <20150129163019.23606.25820@app05.ash-private.bitbucket.org> New issue 670: parallelize rsync in xdist https://bitbucket.org/hpk42/pytest/issue/670/parallelize-rsync-in-xdist Anatoly Bubenkov: Hi in big projects like we have, serial rsyncing takes a lot of time looking the code it seems to be possible to parallelise this process what do you think about this? From issues-reply at bitbucket.org Thu Jan 29 23:01:45 2015 From: issues-reply at bitbucket.org (Buck Evan) Date: Thu, 29 Jan 2015 22:01:45 -0000 Subject: [Pytest-commit] Issue #671: missing fixture setup for doctest module items (hpk42/pytest) Message-ID: <20150129220145.31754.27059@app01.ash-private.bitbucket.org> New issue 671: missing fixture setup for doctest module items https://bitbucket.org/hpk42/pytest/issue/671/missing-fixture-setup-for-doctest-module Buck Evan: For a lack of deep understanding, I'm just transcribing our #pylib conversation to this ticket: ``` (12:58:14 PM) buck11: I don't see that my autouse fixture is running for my doctests, counter to documentation (12:58:39 PM) buck11: known bug? also its quite possible i'm doing it wrong 13:00 (01:01:52 PM) buck11: =/ 13:50 (01:50:31 PM) ronny: buck11: afair doctest fixture integration is not there (01:50:48 PM) buck11: docs explicitly say its there (01:50:50 PM) ronny: (doctests run with custom items, i reall they arent able to handle fixtures) (01:50:50 PM) buck11: sec (01:51:06 PM) ronny: there is a utility function to get fixture values (01:51:10 PM) buck11: http://pytest.org/latest/doctest.html (01:51:12 PM) ronny: but afair autouse is not there (01:51:16 PM) buck11: Also,?using fixtures from classes, modules or projects?and?autouse fixtures (xUnit setup on steroids)?fixtures are supported when executing text doctest files. (01:51:40 PM) buck11: "when executing text doctest files" (01:51:42 PM) ronny: hmmm, what version do you run then (01:51:44 PM) buck11: i guess is the key clause (01:51:51 PM) buck11: i was doctesting code (01:52:04 PM) buck11: i updated a second ago (01:53:21 PM) ronny: buck11: i checked the code, the doctest text file has explicit code for that detail, the doctest module thing hasnt (01:53:36 PM) buck11: hrm i expected them to be more similar (01:53:42 PM) buck11: shrug 13:55 (01:55:01 PM) ronny: buck11: doctest is a bit messy, there is also fixture code in the doctest modules (01:55:09 PM) ronny: buck11: how are your fixtures scoped? (01:55:36 PM) buck11: it was forced to be function scope, because i wanted to leverage monkeypatch fixture (01:55:50 PM) buck11: i've solved it a different way entirely now (01:56:42 PM) buck11: ronny: https://github.com/bukzor/python-clom/commit/04e3bab93#diff-1 (01:56:47 PM) buck11: sadness, but it works (01:56:48 PM) ronny: hmm, as far as i can tell docestmodule can use a overhaul, unlike the textfile, it doesnt use FixtureRequest._fillfixtures (01:57:58 PM) ronny: buck11: can you report a bug? (01:58:08 PM) buck11: i dont know what the bug i (01:58:09 PM) buck11: s (01:58:24 PM) ronny: missing fixture setup for doctest module items ``` Responsible: RonnyPfannschmidt