pytest blows up when collecting modules with uninspectable objects

[pytestbot]

Originally reported by: Thomas Waldmann (BitBucket: thomaswaldmann, GitHub: thomaswaldmann)

---

werkzeug/flask offers some threadlocals to comfortable access stuff like (http) request, session, (wsgi) app, etc. - those objects are special and only valid when a request is running or an app was created.

if you access them before / after they are valid, it'll raise a RuntimeError.

while collecting tests, pytest (since 2.3) accesses all module-level objects and tries to inspect them for a specific attribute, causing a RuntimeError exception when it does that on such special objects.

thus, the usual code used in about every flask app makes pytest unusable:

from flask import request, session # <- threadlocals

a simple patch that solves the issue is attached.

---

• Bitbucket: https://bitbucket.org/pytest-dev/pytest/issue/214

[pytestbot]

Original comment by Thomas Waldmann (BitBucket: thomaswaldmann, GitHub: thomaswaldmann):

---

maybe fix the comment in the patch to say "flask/werkzeug's threadlocals".
the implementation is in werkzeug, but (IIRC) only flask uses session/request.

[pytestbot]

Original comment by Ronny Pfannschmidt (BitBucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt):

---

its missing a test

i think we should catch the specific exceptions, will fix

[pytestbot]

Original comment by Thomas Waldmann (BitBucket: thomaswaldmann, GitHub: thomaswaldmann):

---

well, i manually tested it, with a flask import, but i doubt you want a flask dependency in pytest's tests.

[pytestbot]

Original comment by Thomas Waldmann (BitBucket: thomaswaldmann, GitHub: thomaswaldmann):

---

i first had a more specific exception handler, but then decided to rather be more general. you basically don't know what exceptions could happen.

usually one would go for an AttributeError at that place, but then the threadlocals would still blow up things, as they raise RuntimeError.

[pytestbot]

Original comment by Ronny Pfannschmidt (BitBucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt):

---

i meant to catch only a runtimeerror, and test it with a fake object

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

I think it's safe to catch more generically (except KeyboardInterrupt etc.). This particular issue is about parsing fixtures - if for some very unlikely reason there is a real issue underlying the exception, the according pytest-fixture function wil not be available and cause other problems.

[pytestbot]

Original comment by Ronny Pfannschmidt (BitBucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt):

---

fix issue 214 - gracefully handle proxy objects that look like fixtures

[pytestbot]

Original comment by Ronny Pfannschmidt (BitBucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt):

---

i currently only tested agains RuntimeError,
i'd like to keep it as specific as possible, since i'd like to avoid hiding real errors

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

extended - fix issue214 - ignore attribute-access errors with objects in test modules that can blow up (for example flask's request object)