
If you've ever run a Cypress test and it failed without a clear reason, you know how tricky debugging can be. Small issues like timing problems, unexpected page behavior, or minor coding errors can make tests fail even when the code looks correct.
Cypress offers several tools to help uncover what went wrong. From reading stack traces to using commands like .debug() and .pause(), these tools let you inspect tests step by step and see exactly where issues occur.
In this article, I will walk through practical ways to debug Cypress tests. You will learn how to read stack traces, use the debugger, add console logs, and leverage commands like .debug() and .pause().
Debugging Cypress tests provides a clear view of how tests interact with the application. It exposes hidden issues, helps stabilize test execution, and allows testers to make precise corrections.
Debugging in Cypress can feel overwhelming at first, but the framework provides several tools to inspect test execution and understand why a test fails. Using these methods systematically helps uncover hidden issues and ensures tests remain stable and maintainable.
Below are the top five ways to debug Cypress tests effectively.
When a test fails, Cypress automatically generates a stack trace showing where the failure occurred. Stack traces provide details about the exact command, the file, and the line number, which is critical for pinpointing the source of the problem.
Example:
it('should display the correct title', () => {
cy.visit('/dashboard')
cy.get('h1').should('contain', 'Dashbord') // typo causes failure
})
Cypress will output an error with a stack trace pointing to the line with 'Dashbord'. Reviewing the stack trace quickly identifies the assertion failure and the affected test step.
Best Practices:
Cypress integrates seamlessly with JavaScript’s debugger statement. When Cypress encounters a debugger, it pauses execution, allowing you to inspect variables and DOM state in the browser’s DevTools.
Example:
it('checks user profile', () => {
cy.visit('/profile')
cy.get('.user-name').then(($el) => {
debugger // execution pauses here
expect($el.text()).to.equal('John Doe')
})
})
Tips:
Console logs are simple but powerful. Adding cy.log() or console.log() statements helps track variable values, test flow, and conditional logic.
Example:
it('verifies cart total', () => {
cy.get('.cart-item').then(($items) => {
console.log('Number of items in cart:', $items.length)
cy.log('Cart contains ' + $items.length + ' items')
})
})
Benefits:
The .debug() command pauses the test at a specific Cypress command and prints the current subject in the console. This is useful for inspecting elements or state without stopping the entire test suite.
Example:
cy.get('.todo-item').first().debug().should('contain', 'Buy milk')
Key Points:
.pause() halts test execution entirely, letting you interact with the page manually in the Cypress Test Runner. This is ideal for investigating intermittent issues or complex UI interactions.
Example:
cy.get('#checkout-button').click()
cy.pause()
cy.get('.confirmation-message').should('be.visible')
How to Use:
Both .pause() and .debug() are essential tools in Cypress, but they serve slightly different purposes.
.pause() stops the entire test, giving you a chance to manually interact with the page and observe its state, which is useful for complex workflows or intermittent issues. .debug(), on the other hand, focuses on a specific Cypress command or element, printing its current state to the console without halting the rest of the test flow.
| Feature | .pause() | .debug() |
| Execution Halt | Stops the entire test | Pauses only the current subject |
| Interactivity | Allows manual inspection | Only prints current element/subject in console |
| Best Use | Complex flows or intermittent failures | Quick inspection of a specific element or variable |
| Integration | Test Runner pause button | DevTools console inspection |
Rule of Thumb: Use .pause() when you want to interact with the application during a test. Use .debug() when you need to inspect the current element or state without stopping the test flow.
Debugging Cypress tests directly in VS Code combines the power of Cypress commands with a familiar development environment. Setting up VS Code to run Cypress in debug mode allows you to set breakpoints, inspect variables, and step through test execution line by line.
This is especially helpful for complex tests or when diagnosing issues that do not reproduce consistently in the Cypress Test Runner.
Setting Up VS Code for Cypress Debugging:
{
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Debug Cypress Tests",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}"
}
]
}
Once the debugger is attached, you can step through your tests, inspect variables, and observe DOM changes in real time. For issues that only appear in specific browsers or devices, tools like BrowserStack let you run the same tests across multiple real environments in the cloud. This helps ensure that what you debug locally matches how the application behaves for actual users.
Even with Cypress’s built-in tools, testers often encounter common issues that make debugging harder. These can include timing problems, flaky assertions, or elements not being visible when expected. Understanding these pitfalls helps fix tests faster and prevent repeated failures.
Debugging Cypress tests is essential for creating reliable and maintainable test suites. Using stack traces, console logs, .debug(), .pause(), and VS Code breakpoints helps uncover why tests fail and provides clear insight into how your application behaves during automated testing.
Tools like BrowserStack make this process even smoother by letting tests run across multiple browsers and real devices in the cloud. This ensures that environment-specific issues are caught early, so debugging reflects real-world conditions and delivers more dependable results.
Get visual proof, steps to reproduce and technical logs with one click
Try Bird on your next bug - you’ll love it
“Game changer”
Julie, Head of QA
Try Bird later, from your desktop