Show XHR responses

[peruukki]

Currently cypress-terminal-report only shows XHR requests when they are sent and doesn't show anything related to the server responses. It would be useful to see at least the server response status codes in the logs when investigating test failures.

The Cypress UI adds the response information to the initial request message in its command log once it arrives, but I would actually rather see the responses as their own log messages, so that we see when those responses arrived during the test execution. This would be very helpful in investigating flaky tests, which are often caused by irregular timings of network requests.

To easily separate the requests from the responses, they could have different log types, e.g. cy:xhr:req and cy:xhr:res. Here's an example of how it could look when running xhrTypes.spec.js:

      cy:command ✔  visit	/commands/network-requests
      cy:command ✔  get	.network-put
      cy:command ✔  click	
      cy:xhr:req ⓘ  STUBBED PUT https://jsonplaceholder.cypress.io/comments/1
        cy:route ⚠  (putComment) PUT https://jsonplaceholder.cypress.io/comments/1
                    Status: 403
                    Response body: {
                      "key": "data"
                    }
      cy:xhr:res ⚠  403 (Forbidden) PUT https://jsonplaceholder.cypress.io/comments/1
      cy:command ✔  wait	@putComment
      cy:command ✘  get	.breaking-get

We could also include the response body, but that should be somehow limited to avoid flooding the logs, e.g. only show it for non-2xx responses (that would be also shown as warnings).

What do you think of this idea, could this funtionality be added? I could work on a PR for it. The XHR responses are sent to the log:changed listener.

[archfz]

Mostly sounds good. I would leave 'cy:xhr' and add 'cy:xhr:res' to avoid breaking change. Only showing response data when the endpoint is failing also makes sense.

The only problem I have with this is that in case of xhr that are actually captured by cy route we would be displaying the information twice as I understand. Maybe we should investigate if we can somehow detect this duplication and do not log twice.

[peruukki]

Maybe we should investigate if we can somehow detect this duplication and do not log twice.

Looks like each XHR has an ID field, so we can keep track of logged XHR IDs to avoid duplication.

[peruukki]

When writing tests for this, I noticed that the XHR response log updates are not sent immediately, and sometimes Cypress manages to log a couple commands after it actually received the response, before we receive the XHR response log update. This makes logging the responses separately pretty much useless and even potentially misleading. 😞

But we could still update the original XHR log message like Cypress UI does. And to give some indication of how long the XHR took, we could show the duration given by options.consoleProps.Duration. It includes the duration of the network request plus some little extra delay, e.g. for one request Chrome's Network tab showed 1.03 seconds and Cypress reported 1040 ms.

Here are some ideas how the XHR log could, considering different cases:

• Stubbed request using cy.route, no response body shown:

  cy:xhr ⚠  403 (Forbidden) STUBBED PUT https://jsonplaceholder.cypress.io/comments/1 (1.04 s)
  

• Or the status on its own line like with cy:route:

  cy:xhr ⚠  STUBBED PUT https://jsonplaceholder.cypress.io/comments/1 (1.04 s)
            Status: 403 (Forbidden)
  

• Non-stubbed request, with response body:

  cy:xhr ⚠  403 (Forbidden) PUT https://jsonplaceholder.cypress.io/comments/1 (1.04 s)
            Response body: {
              "key": "data"
            }
  

• Or similarly to cy:route:

  cy:xhr ⚠  PUT https://jsonplaceholder.cypress.io/comments/1 (1.04 s)
            Status: 403 (Forbidden)
            Response body: {
              "key": "data"
            }
  

In this case, it would probably make sense to always update the XHR log with the response status and duration, but maybe still only show the response body if it is not logged by cy.route and if the request failed?

[archfz]

Updating the logs always instead of writing them separately sounds better to me. It's more clear that way. And in that case we indeed need to support 2 formats: one where we only log the request (in case we didn't receive the log update from cypress: ex after test finishes) and one where we log it both request and response.

Logging the time spent on request is a good feature and if we always get that information easily then why not. I would leave this always enabled as why would we disable it ?

Regarding which format to show with the status code placement: I like the one where we show on the same line with the url. But we should also keep consistency with the cy.request logging.

[archfz]

Released in 2.4.0