Problem

Many of our users express the desire to see console.log statements when running headlessly. Typically you'd be able to see these when you're working in Dev Tools (in headed GUI mode).

We can pretty easily display console.log statements by mixing them into stdout when running headlessly, but we don't think this is really a "true" solution. It's kind of a hack and it still doesn't really tell you "everything" that's happening. For instance, when a console.log happens, how would you know when it happened in relation to everything else that's going on in a test?

So, we think to truly solve this problem, we need a comprehensive way of displaying not just console.log statements but also capturing:

• Network Traffic
• Commands
• Retries
• Under the hood Cypress wizardry
• DOM snapshots on failure

By providing all of this, the entire picture of what happened during a test is revealed and now you actually have even more information at your disposal than even what the GUI headed version provides you.

Solution

The logs will be available in the Cypress Cloud.

Once we capture and parse these logs, it will unlock an enormous amount of power in Cypress. We'll also be able to analyze the logs and deliver things like:

• Analytics into your tests
• Comparing a failing test to a previously passing one
• Diffing the logs for changes in response bodies, etc
• Understanding why tests are slow
• Discovering command anti patterns (like explicit waits in your code)

The logs could also be interactive - for instance they should "sync" up to the video and enable you to playback everything that actually happened in a Cypress test.

Here is an example comp of what we're going for.

We're still working on communicating the start and end of logs, and also communicating that a log event acts as "a stream" but that events are connected to other events.

For instance when a HTTP request starts - that's a 'start' event. When the response comes back, thats a separate 'end' event. However these are connected and you likely need to be able to view the data for both events from either the start or end event.

Another example:

A command starts. It retries 65x times. It eventually finishes. The duration of the retry events, the reason its retrying, and the eventual delta between a start and an end needs to be communicated intelligently.

These log files end up being a massive amount of data, but we already have the infrastructure in place to capture, parse and deliver them. At this point we're just iterating on a UI that's intuitive and doesn't overwhelm the user.

We're going to be providing a new Logs tab, but also for individual test failures, we'll just be providing the logs for that one independent test.

Feedback

...is welcome ;-)