treq.testing.RequestSequence

For an example usage, see :meth:`RequestSequence.consume`. Takes a sequence of:: [((method, url, params, headers, data), (code, headers, body)), ...] Expects the requests to arrive in sequence order. If there are no more responses, or the request's parameters do not match the next item's expected request parameters, calls `sync_failure_reporter` or `async_failure_reporter`. For the expected request tuples: - ``method`` should be :class:`bytes` normalized to lowercase. - ``url`` should be a `str` normalized as per the `transformations in that (usually) preserve semantics <https://en.wikipedia.org/wiki/URL_normalization>`_. A URL to `http://something-that-looks-like-a-directory` would be normalized to `http://something-that-looks-like-a-directory/` and a URL to `http://something-that-looks-like-a-page/page.html` remains unchanged. - ``params`` is a dictionary mapping :class:`bytes` to :class:`list` of :class:`bytes`. - ``headers`` is a dictionary mapping :class:`bytes` to :class:`list` of :class:`bytes` -- note that :class:`twisted.web.client.Agent` may add its own headers which are not guaranteed to be present (for instance, `user-agent` or `content-length`), so it's better to use some kind of matcher like :class:`HasHeaders`. - ``data`` is a :class:`bytes`. For the response tuples: - ``code`` is an integer representing the HTTP status code to return. - ``headers`` is a dictionary mapping :class:`bytes` to :class:`bytes` or :class:`str`. Note that the value is *not* a list. - ``body`` is a :class:`bytes`. :ivar list sequence: A sequence of (request tuple, response tuple) two-tuples, as described above. :ivar async_failure_reporter: An optional callable that takes a :class:`str` message indicating a failure. It's asynchronous because it cannot just raise an exception—if it does, :meth:`Resource.render <twisted.web.resource.Resource.render>` will just convert that into a 500 response, and there will be no other failure reporting mechanism. When the `async_failure_reporter` parameter is not passed, async failures will be reported via a :class:`twisted.logger.Logger` instance, which Trial's test case classes (:class:`twisted.trial.unittest.TestCase` and :class:`~twisted.trial.unittest.SynchronousTestCase`) will translate into a test failure. .. note:: Some versions of :class:`twisted.trial.unittest.SynchronousTestCase` report logged errors on the wrong test: see `Twisted #9267 <https://twistedmatrix.com/trac/ticket/9267>`_. .. TODO Update the above note to say what version of SynchronousTestCase is fixed once Twisted >17.5.0 is released. When not subclassing Trial's classes you must pass `async_failure_reporter` and implement equivalent behavior or errors will pass silently. For example:: async_failures = [] sequence_stubs = RequestSequence([...], async_failures.append) stub_treq = StubTreq(StringStubbingResource(sequence_stubs)) with sequence_stubs.consume(self.fail): # self = unittest.TestCase stub_treq.get('http://fakeurl.com') self.assertEqual([], async_failures)