Xdebug breakpoints always work except when using @

2019-02-26 15:17发布

I finally got Xdebug working (including with breakpoints and the ability to "step over") for unit tests, feature tests, and for poking around in the browser.

However, whenever I use @runTestsInSeparateProcesses because of this reason, Netbeans breakpoints no longer work.

How can I use Xdebug breakpoints on tests that use @runTestsInSeparateProcesses?

I'm using Netbeans 8.2 on Windows 10 Version 1607 Build 14393.0. PHPUnit 5.7.21.

I'm running Laravel 5.4 Homestead (which is Vagrant 1.9.5), so that means my server is Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-66-generic x86_64).

1条回答
对你真心纯属浪费
2楼-- · 2019-02-26 15:46

You need to add the xdebug configuration to your php.ini so that if phpunit invokes the php-interpreter another time (b/c of @runTestsInSeparateProcesses) to run the test in a separate process is loaded and has xdebug activate automatically (remote debug settings etc.) w/o any further parameters passed to the executable.

If you have done this already (which might not be the case from your question), ensure that your IDE is accepting more than a single xdebug connection (xdebug connection limit or similar). This is necessary as a new PHP process will start a new xdebug remote session which needs an additional connection. If that connection is not fulfilled, xdebug will wait so with a connection limit of one (1) for example, you will see that PHP hangs.

The drawback with this approach is that xdebug will be loaded always which will add ca. 10% performance onto PHP executed within the CLI.

As far as this is on a development box, you can create yourself some script you can run to switch xdebug default configuration on and off for the installed PHP binary.

Composer is not affected by this as it will re-launch itself with xdebug disabled, but most other PHP cli tools don't do this (and perhaps don't need it as there is so much performance available and the drawback can be neglected. it's mostly important for PHP scripts that do a lot of object creation and such).

So, setup your php.ini and enable xdebug. A good IDE shows the settings it automatically adds (PHP cli -d options), just add these to your php.ini and you should be fine for that testing scenario.

When you get it to work, think about how to disable settings on the fly (sed is handy for that, especially with -i [edit In place] on GNU systems, Stackoverflow should keep you happy with the basics here, for Windows I can't say what is working well, in case you wonder).

Additional note: I can't specifically say for Netbeans as I don't use it, but with Phpstorm this is quite the same (I assume in good faith) as it adds xdebug to the PHP configuration when invoked for tests (debug, coverage), and spawned sub-process which lead to other PHP scripts can't be debugged unless I put that added xdebug configuration into the php.ini.

查看更多
登录 后发表回答