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

`requests` call failures in pytest fixtures displays class content in errors #3018

Closed
phtrivier opened this Issue Dec 11, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@phtrivier

phtrivier commented Dec 11, 2017

I'm using pytest to run "black-box" testing against a running web application, using requests for http.

When the http call fails (for any reason), this causes the pytest test to fail, with a very verbose output that actually contains the code from some requests class:


stack = <utils.local_stack.LocalStack object at 0x7f6a17694518>

    @pytest.fixture(scope="function")
    def prepare(stack):
>       response = api.do_some_http_call()

tests/conftest.py:54: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
apis/redacted.py:36: in do_some_http_call
    return requests.get(.... some url ... )
../../../../.local/lib/python3.6/site-packages/requests/api.py:72: in get
    return request('get', url, params=params, **kwargs)
../../../../.local/lib/python3.6/site-packages/requests/api.py:58: in request
    return session.request(method=method, url=url, **kwargs)
../../../../.local/lib/python3.6/site-packages/requests/sessions.py:508: in request
    resp = self.send(prep, **send_kwargs)
../../../../.local/lib/python3.6/site-packages/requests/sessions.py:618: in send
    r = adapter.send(request, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <requests.adapters.HTTPAdapter object at 0x7f6a1740ae80>, request = <PreparedRequest [GET]>, stream = False, timeout = <urllib3.util.timeout.Timeout object at 0x7f6a1740ac50>, verify = True, cert = None, proxies = OrderedDict()

    def send(self, request, stream=False, timeout=None, verify=True, cert=None, proxies=None):
        """Sends PreparedRequest object. Returns Response object.
    
            :param request: The :class:`PreparedRequest <PreparedRequest>` being sent.
            :param stream: (optional) Whether to stream the request content.
            :param timeout: (optional) How long to wait for the server to send
                data before giving up, as a float, or a :ref:`(connect timeout,
                read timeout) <timeouts>` tuple.
            :type timeout: float or tuple or urllib3 Timeout object
            :param verify: (optional) Either a boolean, in which case it controls whether
                we verify the server's TLS certificate, or a string, in which case it
                must be a path to a CA bundle to use
            :param cert: (optional) Any user-provided SSL certificate to be trusted.
            :param proxies: (optional) The proxies dictionary to apply to the request.
            :rtype: requests.Response
            """

   ... etc ... 

Is it the expected behavior of pytest ? Could it be because the Exception is raised in a fixture from conftest.py ? How can I make the output more readable (I really only want the stacktrace, not the full code...)

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Dec 11, 2017

This is the intended behavior, pytest doesn't know or does any special treatment regarding requests. But you can control the traceback output, checkout the --tb option:

  --tb=style            traceback print mode (auto/long/short/line/native/no).

You probably want native or short.

@nicoddemus

This comment has been minimized.

Member

nicoddemus commented Sep 2, 2018

Closing as this has not seen activity in awhile.

@nicoddemus nicoddemus closed this Sep 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment