Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pytest 3.0 does not accept empty list in fixture #1849

Closed
OPpuolitaival opened this issue Aug 23, 2016 · 7 comments
Closed

Pytest 3.0 does not accept empty list in fixture #1849

OPpuolitaival opened this issue Aug 23, 2016 · 7 comments
Labels
type: regression indicates a problem that was introduced in a release which was working previously

Comments

@OPpuolitaival
Copy link

OPpuolitaival commented Aug 23, 2016

With pytest 2.x it was very easy to use empty lists in fixture if dynamically run test case did not find anything to test. pytest 3.x seems to accept only None values.

Also when setting empty list in fixture with pytest 3.x the error message is very ugly

example code:

@pytest.fixture(scope="module", ids=list(), params=list())
def temp(request):
   return request.param

def test_temp(temp):
     pass

(edited by @The-Compiler to add code blocks)

@The-Compiler
Copy link
Member

For reference, this is the behavior with 2.9.2:

============================================ test session starts =============================================
platform linux -- Python 3.5.2, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: /home/florian, inifile: 
plugins: mock-1.2
collected 1 items 

x.py s

========================================= 1 skipped in 0.00 seconds ==========================================

With 3.0.0:

============================================ test session starts =============================================
platform linux -- Python 3.5.2, pytest-3.0.0, py-1.4.31, pluggy-0.3.1
rootdir: /home/florian, inifile: 
plugins: hypothesis-2.0.0, catchlog-1.2.1
collected 0 items / 1 errors 

=================================================== ERRORS ===================================================
___________________________________________ ERROR collecting x.py ____________________________________________
.venv/lib/python3.5/site-packages/_pytest/runner.py:163: in __init__
    self.result = func()
.venv/lib/python3.5/site-packages/_pytest/main.py:460: in _memocollect
    return self._memoizedcall('_collected', lambda: list(self.collect()))
.venv/lib/python3.5/site-packages/_pytest/main.py:331: in _memoizedcall
    res = function()
.venv/lib/python3.5/site-packages/_pytest/main.py:460: in <lambda>
    return self._memoizedcall('_collected', lambda: list(self.collect()))
.venv/lib/python3.5/site-packages/_pytest/python.py:404: in collect
    return super(Module, self).collect()
.venv/lib/python3.5/site-packages/_pytest/python.py:318: in collect
    res = self.makeitem(name, obj)
.venv/lib/python3.5/site-packages/_pytest/python.py:330: in makeitem
    collector=self, name=name, obj=obj)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:724: in __call__
    return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:338: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:333: in <lambda>
    _MultiCall(methods, kwargs, hook.spec_opts).execute()
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:595: in execute
    return _wrapped_call(hook_impl.function(*args), self.execute)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:249: in _wrapped_call
    wrap_controller.send(call_outcome)
.venv/lib/python3.5/site-packages/_pytest/python.py:191: in pytest_pycollect_makeitem
    res = list(collector._genfunctions(name, obj))
.venv/lib/python3.5/site-packages/_pytest/python.py:350: in _genfunctions
    self.ihook.pytest_generate_tests(metafunc=metafunc)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:724: in __call__
    return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:338: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:333: in <lambda>
    _MultiCall(methods, kwargs, hook.spec_opts).execute()
.venv/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py:596: in execute
    res = hook_impl.function(*args)
.venv/lib/python3.5/site-packages/_pytest/fixtures.py:1028: in pytest_generate_tests
    ids=fixturedef.ids)
.venv/lib/python3.5/site-packages/_pytest/python.py:846: in parametrize
    ids = idmaker(argnames, argvalues, idfn, ids, self.config)
.venv/lib/python3.5/site-packages/_pytest/python.py:933: in idmaker
    for valindex, valset in enumerate(argvalues)]
.venv/lib/python3.5/site-packages/_pytest/python.py:933: in <listcomp>
    for valindex, valset in enumerate(argvalues)]
.venv/lib/python3.5/site-packages/_pytest/python.py:924: in _idvalset
    if ids is None or ids[idx] is None:
E   IndexError: list index out of range
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
========================================== 1 error in 0.52 seconds ===========================================

@nicoddemus
Copy link
Member

Could someone bisect this so we can discuss if this was unintended or there was the intent of making this an error (in which case we should work on the message of course)?

@The-Compiler
Copy link
Member

Bisected to be1954a with a git bisect run ./.venv/bin/py.test x.py and 20sec of waiting 😉

cc @palaviv

@nicoddemus
Copy link
Member

nicoddemus commented Aug 23, 2016

@The-Compiler thanks! I didn't do it myself because I'm at work right now and would like to get the ball rolling. 😁

@The-Compiler
Copy link
Member

@nicoddemus Sorry if that sounded like "why didn't you do it yourself?", it was meant as a "git bisect run is awesome!" 😉

@nicoddemus
Copy link
Member

Please, not at all! I was just asking because I couldn't really spend the time doing it myself, thanks for doing it.

@nicoddemus nicoddemus added the type: regression indicates a problem that was introduced in a release which was working previously label Aug 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression indicates a problem that was introduced in a release which was working previously
Projects
None yet
Development

No branches or pull requests

3 participants