Debugging Cypress Tests with Chrome DevTools MCP

Añadido: 2026-06-03

[00:00:04]Hi everyone. I want to walk through a quick demo of a local workflow that I've been using where I'm connecting the Chrome DevTools MCP to a local Cypress launch browser.

[00:00:14]It's quick to set up and it has unlocked quite a bit in my day-to-day agentic workflows.

[00:00:21]In this demo, I'm going to use cursor and I'm going to use a Cypress to-do app. Um just for a little bit of background context, I recently had cursor update the behavior of this to-do app. So, when an item when you go to delete an item from the list, it's no longer automatically removed and instead you have to actually say yes, delete it um or cancel the action.

[00:00:43]So, now that this behavioral change is in place, I actually have a test failure that I need to go fix. So, the first thing we need to do is we need to set up the Chrome DevTools MCP and we need to establish a connection between this MCP tool and the Cypress launch browser.

[00:01:00]Here I am in cursor looking at my mcp.json where I've configured the Chrome DevTools MCP. And the key thing with this configuration is I've explicitly defined the port 59,210.

[00:01:16]When the Chrome DevTools MCP launches, it's going to look for a Chrome browser with this debugging port enabled. If you had not set this, it's going to launch its own instance. It won't connect. It's really not what we want because we want to be connected to the Cypress launch Chrome browser.

[00:01:35]So, moving over here, I can establish this connection with Cypress through the Cypress remote debugging port.

[00:01:43]And when it launches, it's going to launch this Chrome browser with that same port, which means that the MCP tool and the Cypress browser will be able to connect. So, I just kicked off the spec where I was seeing this test failure.

[00:01:57]Just so that we could see for ourselves that indeed, yes, we do have a failing test. And here inside of Cursor, I just prompted my agent to use the Chrome DevTools MCP to check the current status on the page and see if it sees any test failures.

[00:02:13]And as we can see, it is seeing the same results that we can see here in the Cypress app. It sees six passing tests, one failing test, and it was able to identify which test was failing, the error that it was observing, um everything else. So, this is interesting. This is like the base context that we need to help kick off a debugging workflow, right? Now, this is a big part of seeding the context. And the secondary part here is we want to actually fix test. We don't need to run Cypress because we have our local instance already running. But here, I'm asking my agent, "Hey, go fix this failure, but also consider the changes that have already been made on this branch." We already know that it's a behavioral change within the application. So, this should result in a test update because the test is actually the piece that's broken here. Of course, you never want to assume it's your test that's failing because there are definitely times where your application is unintentionally changing the behavior that should actually match what the test is is testing, right? But as I was talking, you can see that Cursor was able to identify the behavioral change, and it applied that. And when it saved that spec, because the Cypress application has file watchers enabled, the launch Cypress app picked those changes up and reran, and we can see here that now all of the tests are passing. One key thing to note with this workflow really does unlock a lot, but you're not locked into the latest Cypress version to start using this. The Cypress remote debugging port environment variable, that's been around for many Cypress versions. So, you could start using this today even if you're not on the latest I burst version. So, as always, it's best to be up to date.

[00:03:57]We've been doing a lot of performance improvements recently, but either way, this can unlock you now and move forward with this agentic kind of workflow.

[00:04:06]Here, we saw success where the agent was able to identify the correct change and make the update and our tests are now passing. But, if you're ever in an instance where you'd want to put this in a skill or do other things, you could support more autonomous workflow where you're not going to need a prompt it along the way. So, there's a lot you can do with this, a lot you can play with.

[00:04:25]And I just wanted to share this as a way to get started with your local debugging loop.