00:00 The problem with this test is that my component renders the dashboard menu item as active when it shouldn't be. So to fix this, it'll be nice to stop the execution right before it renders that item and take a look around. This means that I won't be adding breakpoints anywhere in my test, but instead in the component itself.

00:17 So if I go to the implementation, I can see it uses another component, and here's the iteration over the menu items. It would be nice if I can add breakpoints, let's say, somewhere on this line, where this is active prop from React Router, and then decide which styles to apply and so forth.

00:32 But if I do this, it will stop the execution on every menu item, and I don't want that. I don't want to jump between the breakpoints until I reach the right item. That would be a time waste. So instead, I will remove this breakpoint and right-click here, and instead add a conditional breakpoint.

00:48 Basically, this will tell my IDE to only trigger this breakpoint when a particular expression or condition is met. In my case, the condition is for the item title to equal to dashboard. And once I do this, I can press enter, and this will add a conditional breakpoint on this line.

01:05 There is just one problem with this approach. Breakpoints and the conditions for those breakpoints can only reference values that are present in the current scope. The scope here is this class name function, this one. And in this scope, there is no item available, this item that we're trying to render.

01:23 Although you can technically reference it here from the parental closure, it's not defined in this closure. So conditions that try to reference things that are not defined in this closure, but the breakpoint is in, they will fail. So to fix this, I can go to this condition here and add the reference to the item object like this.

01:39 This will not change the way this condition works, but instead add the reference to this item so I'm able to use it as a condition for my breakpoint. So once I have this, let's save it and run our test using this debug command here. So debug-vidas-test, make sure, and click run. Select the test and OK.

01:59 This will spawn the browser, but I want to show you what you can do in the IDE to debug this issue instead. Let's clear this console. There's a lot of things going on, but let's unwrap them. So first, the test stopped on render. Once again, we're using inspect break flag. Let's just skip it. And now we reach this breakpoint, which we set over here.

02:18 So our conditional breakpoint from here. We can see that the isActive variable from the scope here as an argument to class name over there is true. And in the parental closure, we can check that the item that we're rendering is indeed the dashboard item, which is nice. So to figure out what's wrong, we need to take a look why this isActive value is true

02:37 for some reason when it shouldn't be. To do that, let's head to this call stack and go to the previous entry here to the nav link with ref. Once I click this, I can see that this is the component from React Router that renders this navigation link. And it has this isActive value over here.

02:53 I can see where it's assigned and even the value of this assignment live at the point of this breakpoint. So what I can do here, I actually have access to all of the things available in this scope. This is one of the things about breakpoints, they're immensely powerful.

03:09 They not only read only, but they allow you to interact with the code around the breakpoint. For example, I can reference variables like location path name and see that right now the location of the document is the one I expect, the one I set in tests. And also I can get the two path name. That is the path name of the link I'm trying to render.

03:28 And I can see that these two are not the same. The assignment here basically checks if they're the same. They're not. And if they're not, it relies on this end prop. And if it's not set or false, then it performs this assignment. This is interesting. So how about we check this end? So the end value is false.

03:47 I can also check it in line here if I hover over it. So it will check this expression. I can even paste it like this, and I can see that it will resolve to true. In other words, since the location of the document starts with the location of the link, with the URL of the link, it considers the link as active.

04:07 This is a mistake on my end. I should have went and marked these navigation links as the ones having end true. This will tell the React router that these URLs must be matched exactly. So I can save it and try to rerun my test. So once again, render. We're getting to the dashboard link over here.

04:26 And now we can see that isActive is finally false. And if we continue with the test run and go to the terminal, yep, continue, we can see that now this test for the active link is finally passing. So to recap here, breakpoints are incredibly valuable and powerful.

04:44 You can stop the code execution at any point in time in your test, whether you're putting breakpoints in the test itself or in the component that you're testing. You can look around, you can go down the stack trace, and even evaluate things in the current closure. That is a lot of power, so I hope you use it well.