We had a different approach altogether. We do something like this, which
prints both the diff and the content, but doesn’t print the content if
there’s no failure:
assert response.status == 200, response.content.decode('utf-8')
Now the response content is used as the assertion error message, so i
Not sure if this would work for your setup, but we solved that by defining
a generic api client class with a logging method that's added to the hooks
on the response object of the requests library. Each specific api client
class then inherits from the generic one.
Regards,
Joep
On Thu, Jun 13, 20
Thanks for the replies.
We do already use the print-before-assert pattern. It'd be nice to be able
to fold this away in a hook so each individual request test doesn't need to
think about it. But using print() is perfectly fine too :)
On Thu, 13 Jun 2019 at 19:35, Joep Schuurkes wrote:
> Hi,
Hi,
On Thu, Jun 13, 2019, 10:25 Florian Bruhin wrote:
> Hey,
>
> On Thu, Jun 13, 2019 at 12:02:01PM +1200, Craig de Stigter wrote:
> > This output isn't terribly useful at present. We'd like to automatically
> > dump the request body (`r.content`) in the output, wherever it's a django
> > respon
Hey,
On Thu, Jun 13, 2019 at 12:02:01PM +1200, Craig de Stigter wrote:
> This output isn't terribly useful at present. We'd like to automatically
> dump the request body (`r.content`) in the output, wherever it's a django
> response object, to aid debugging.
It'd be cool if this were possible wit
Hi there
Considering this failed assertion where a django test request failed:
```
> assert r.status_code == 201
E assert 400 == 201
E -400
E +201
```
This output isn't terribly useful at present. We'd like to automatically
dump the request body (`r.content`) in the o
