Next up, let's get a nice workflow for debugging set up. Now the reality is, this always ends up being a little bit confusing. So luckily, Jose from Tighten has figured all of this out for us, so that we don't have to research and figure out, okay, what do I pull in? What setting do I change? How do I just get this working in my editor? None of us can ever remember how, so it's really useful to document these things. All right, so let's just go through it together. First up, we need to install XDebug, and here we're doing that through Homebrew. You can go to brew.sh on the Mac to pull that in. It's incredibly useful. I highly recommend it. Otherwise, if you're on Windows, I'm sure there's something comparable you can use. All right, so we'll grab that and pull it in, and naturally, you want to grab the version that corresponds to your php installation. In my case, I have 7.1, so that is appropriate. There we go. Next up, find the path to your

pull it in, and naturally, you want to grab the version that corresponds to your php installation. In my case, I have 7.1, so that is appropriate. There we go. Next up, find the path to your XDebug.ini file. All right, here we go. There it is. Let's open that in code, and switch back. We want the file to look like this, so let's grab that. What else? Now we need to install the PHP Debug plugin. All right, Shift Command X, PHP Debug. There it is. Let's grab that and reload, and now we'll go to View and open up the debug panel, or it's Shift Command D. Let's choose an environment now, PHP, and the default should be fine. Okay, so now, Jose's article shows us how to debug a PHP unit test, but you can use this anywhere. So why don't we set foo equals bar right here, and then I will set a breakpoint. Like most editors, I can do that by hovering over here and clicking. Now we can start up our debugger. You'll know it's on if you see this panel here.

right here, and then I will set a breakpoint. Like most editors, I can do that by hovering over here and clicking. Now we can start up our debugger. You'll know it's on if you see this panel here. What next? Well, if we switch back, we need to create an environment variable for XDebug. Now, yes, we could run that in the terminal, but it will, of course, lose effect as soon as you close the tab. So why don't we either do it in our .bashrc or your .zshrc, whatever you prefer. Let's put it right here below. All right, I'll save that and close it out. We're all set to go now. So I will open up the terminal here, and let's make sure we source .zshrc to pull in that change we made. Okay, so I'm just going to run phpunit here. We stop at our breakpoint. So let's inspect it. At this point in time, foo is uninitialized because we haven't yet stopped it. Why don't we go ahead and step over, and now we can see, all right, foo has been set to bar.

inspect it. At this point in time, foo is uninitialized because we haven't yet stopped it. Why don't we go ahead and step over, and now we can see, all right, foo has been set to bar. And further, if we want to drill down to response, baseResponse, here you have a good place to review everything versus doing dd. And you know what? I still frequently do dd. I will sometimes reach for this when I really need to drill down or I need more control. I think both can actually be useful. It just depends. But now you have a pretty seamless workflow. So let's try it one more time. Turn this off, and why don't we do something very simple here. Let's go to route/web. We have this little about page. Why don't we say name equals foo, and I'm going to set a breakpoint right here. Okay, next our test will say we're going to get the about page. All right, we're ready to go. Shift Command D, start debugging, and now let's run phpunit, and there we go. We broke

right here. Okay, next our test will say we're going to get the about page. All right, we're ready to go. Shift Command D, start debugging, and now let's run phpunit, and there we go. We broke there. So at this point we can see, all right, our test hit this exact point, and it looks like name was initialized to foo the way we expect. So yeah, now maybe if it's more dynamic or you're not sure what it is, like you want to say name equals request->name, and you want to make sure that name is being sent through the request properly. Well now we can do it. Start it up, run it again, and we can see, oh, something happened where name didn't get assigned properly, and that's why my code isn't working the way I expect. So let's fix it, and we could say this get about name equals foobar, and we're going to give it another run. There we go. Now we are assigning that variable the way we expect. All right, that's all there is to it. So you should be up and running,