If I will have some more time, I will try to set this up on drupalvm somehow. For this, xdebug.so must be present on vm, but by default neither enabled nor loaded (then you can use the similar CLI trick with prepending PHP settings that load and enable xdebug.so on demand). Otherwise you will get performance penalty on all php-based CLI scripts (including composer, drush etc.), even if you don't intend to debug. Note however that the best practice is to not have xdebug plugin for CLI loaded and enabled globally in php.ini, but to load xdebug plugin only if you want to debug your script. This should not only work for phpunit, but also for any other php-based script. This assumes that you already have installed and enabled xdebug globally in drupalvm config ( php_xdebug_default_enable: 1 in config.yml and xdebug under installed_extras). modules/custom/mymodule/test/src/Unit/MyModuleTest.php PHP_IDE_CONFIG="serverName=v" XDEBUG_CONFIG="remote_host=10.0.2.2". replace 10.0.2.2 with IP address of your Vagrant host machineĮxample (run from docroot/core directory of D8 installation):.replace v with your server name (you will find this in PhpStorm: Languages & Frameworks / PHP / Servers, value of field Name).PHP_IDE_CONFIG="serverName=v" XDEBUG_CONFIG="remote_host=10.0.2.2" To debug phpunit in phpstorm from drupalvm, prepend following settings before the phpunit command (or any other php-based command): Note that the idekey is not set nor is the remote_enable, or remote_connect_back even though I have them set in my config.yml Xdebug.var_display_max_children => 128 => 128 ace_enable_trigger_value => no value => no value Xdebug.show_exception_trace => Off => Off Xdebug.remote_log => no value => no value Xdebug.remote_host => localhost => localhost In search for a way to debug PHP scripts from the CLI, or drush commands more specifically, I stumbled upon PHPStorm’s Zero-configuration Debugging which turned out to be perfect for the job. Xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p JanuOftentimes, I run into issues with drush commands that needed more debugging power than dpm () provides. Xdebug.profiler_output_dir => /tmp => /tmp Xdebug.profiler_enable_trigger_value => no value => no value Xdebug.profiler_enable_trigger => Off => Off Xdebug.force_display_errors => Off => Off Xdebug.file_link_format => no value => no value This site is a Bolt derivative, so all dependencies are managed with composer, and the tests within /var/What is the the workflow for debugging(xdebug) PHPUnit tests for a custom module from within PHPStorm? If I can get this all setup and working I will definitely do a blog post on this one. Here's the thing that's totally throwing me off though. Xdebug and Drupal8 tests (PhpUnit and Simpletest) I've also tried setting up a debug configuration in PHPStorm with the following settings, per slide 22 of the talk below:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |