-
Notifications
You must be signed in to change notification settings - Fork 486
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
More usable html reports : logging the requests and responses in the report and naming entries #1884
Comments
Hi @christopheblin reviewing this issue, I made the link with:
These issue/discussion were about including response bodies when using For |
Hi @christopheblin regarding the size of the HTML report, which can be an issue, we proposed to intoduce a new option
If you want the bodies to be always saved: $ hurl --max-body -1 --report-html /tmp/report.html *.hurl If you want the bodies to be never saved: $ hurl --max-body 0 --report-html /tmp/report.html *.hurl Or we a fixed limitation: $ hurl --max-body 128000 --report-html /tmp/report.html *.hurl |
Problem to solve
When you execute multiple tests, you can use --error-format long to have the response of the failed assertion
However, it is often useful to have the full context of the failure, mostly the body of the request
For ex, if you use a captured variable of a previous request as an input to the failing request, seeing only something like "expected status 200 but was 400" and the body with (hopefully) an error can be insuficient
So you have to find the logs of the test run in order to find the failing request
And sometimes, in order to understand why the payload was like it was, you also need to look at previous calls
Proposal
If the command contains --vey-verbose, then the html report should contain the request AND the response of all entries (or another option "--report-format long")
With this, a better UI would be needed (collapsed sub sections for certificate, request headers, request body, response header, response body for example)
As an additional hint, it would also be great to be able to name the entries
For ex,
would display "Retrieve info" isntead of "Entry 1"
That would allow to have a far more usable reports compared to
Drawabacks
The size of the report is going to be far more important which could be a problem in some circumstances (very long script with lots of HTTP requests)
The text was updated successfully, but these errors were encountered: