Boys and girls, today we are gonna configure PhpStorm which is one heck of an IDE for PHP development, to debug PHP code with Xdebug and Chrome. With these simple steps you can easily start debugging PHP code without headache. First open up the php.ini file and make sure you have enabled remote debugging and profiling for Xdebug. PhpStorm provides a visual representation of profiling data generated by Xdebug or Zend Debugger. You can select several snapshots at a time and collect the aggregated profiling information. Observe an aggregated report and jump from the execution statistics directly to the function in your PHP code.
4 CommentsReading Time:

I use Xdebug not only to hunt bugs, but also for every day development work. Of course I also want to use it when I write my Tests.
I one of my current projects we use Codeception for both Unit- and Acceptance tests. Debugging Codeception Unit tests is as easy as for phpUnit, you just have to make sure that the XDEBUG_SESSION is set as described in my post about CLI debugging with Xdebug.
What to test
The Acceptance tests I want to debug are basically just testing a REST API, so it’s usually firing HTTP GET/POST requests against various endpoints:

[code lang=”php” light=”true”]
class ApiCest
{
public function testDoStuff(ApiTester $I)
{
$I->sendPOST(‘/my/api/dostuff’);

// testing starts here
$I->seeResponseCodeIs(200);
}
}
[/code]
In order to debug the actual “dostuff” endpoint, I have to take care of two things: the debug session Cookie and the PhpStorm debug configuration.
Set the XDEBUG_SESSION cookie
Configure Xdebug Phpstorm
The usual way for me to start a PhpStorm session for non-CLI scripts is to enable the “Start Listening for PHP Debug Connections” in PhpStorm and initiate a request with the XDEBUG_SESSION cookie set.
I’m assuming you have PhpStorm and Xdebug set up neat and nicely, as there are enough tutorials about it out there.
Phpstorm Xdebug Vagrant
This works nicely when I start a debug session using the browser, but now we don’t use a browser and send the requests via HTTP directly (Codeception uses Guzzle for that), so we have to set the Cookie somehow. There are (at least) three ways to do that with Codeception:
Phpstorm Xdebug Ssh
- Set the cookie manually in the Cest (Codeception acceptance test class)
[code lang=”php” light=”true)”]
$I->setCookie(‘XDEBUG_SESSION’, ‘PHPSTORM’);
[/code] - Configure Guzzle to send the Cookie via the codeception.yml
This is described Codeception manual on the PhpBrowser module
- Use the codeception/remote-debug extension
Codeception-Remotedebug on Github
This is my preferred way, it’s actually pretty easy to set up, and this way I just send the Cookie all the time.
[code]
extensions:
enabled:
– CodeceptionExtensionRemoteDebug
config:
CodeceptionExtensionRemoteDebug:
sessionName: PHPSTORM
[/code]Since the Cookie value (PHPSTORM) might be different for other developers, these settings should not be under Version control. Codeception allows several ways to achieve this, in our project we use a environment-specific setup, which is not under version control and allows use to extend or overwrite settings on the project-wide, version controlled codeception.yml. Learn more about it in the Codeception manual on Environments.Increase PhpStorms Max. connections
This might cause some headache if you forget about it. When I tried to all of the above ways to set the Cookie, the debug session was always getting stuck, i.e. PhpStorm was not stopping at the breakpoints and rather did – nothing!
By default, PhpStorm is configured to handle 1 debug session at a time. However in my case, I need to handle 2 debug sessions in parallel now – one debug session for the actual Acceptance test, and one for the API.
And that’s it. I hope this will be useful for other Codeception users as well!
Scroll Up
