How to run WordPress tests in VVV using WP-CLI and PHPStorm 8

Some time ago I wrote an analogous reminder: How to run WordPress tests in VVV using PHPStorm 8. Today I can do it again. And I really mean can instead of a simpler and also possible must. In fact, only some minutes ago I was able to solve this issue.

In my mentioned article, I explained how to do everything for the ´wordpress-develop´ site. It is what allows you to develop the WordPress core, for example for fixing a bug. And with the help of VVV / Vagrant / VirtualBox, setting up the environment is almost a painless task.

At some point I decided it was time to start developing the new version of my very old Enzymes plugin. I thought that it would make a lot of sense to take advantage of the ´wordpress-default´ site which VVV provides too, so I checked out my plugin code from, and, for some days, I could think and write my new code in a PHPStorm project, as I use to.

When I needed to debug an intermittently failing test, I recalled that I had written a reminder about that, and happily read it and applied all those steps again… to no avail. Oops.

Of course there had to be some difference. The first one I could think of was that before I had used the ´phpunit.xml.dist´ configuration file that came packaged with VVV, while now I was trying to use the ´phpunit.xml´ generated by the ´wp scaffold plugin-tests´ command. However it didn’t seem the right issue here.

What absolutely I could not understand was why I could run my PHPUnit tests smoothly from the command line but not from PHPStorm, not even following my own fabulous how-to instructions that had worked so well before. It drove me crazy, and more so because I couldn’t solve it.

From time to time I got back to having a need for debugging my tests, and tried to configure PHPStorm again, but never succeeded.

Today I also tried an alternative I found on the PHPStorm issue tracking site. WI-25653: Path mapping not considered when running PHPUnit tests with remote interpreter… I really wanted the solution outlined in the comment to be the one, but I couldn’t make that work either.

I was very sad. It had to be the solution, because that was almost exactly the problem I had:

Screen Shot 2015-02-12 at 22.25.29

Of course the problem I had was that PHPStorm was trying to access a path in my hosting environment (OSX) thinking it was a path in the hosted environment (Ubuntu). In fact my ´phpunit.xml´ file not only was very real, but I had previously selected it with PHPStorm itself !!

Screen Shot 2015-02-12 at 22.33.05

So I deleted that field, unchecked the Use alternative configuration file, and clicked on that last icon on the right… Just because.

Screen Shot 2015-02-12 at 22.03.27

It opened the PHPUnit dialog, which I knew very well already.

Screen Shot 2015-02-12 at 22.38.44

Well, better to look at the remote configuration.

Screen Shot 2015-02-12 at 22.40.24

Then, all of a sudden, I noticed something that I saw many many times before.

Screen Shot 2015-02-12 at 22.44.43

I checked the Default configuration file and clicked on the button on the right. It opened this:

Screen Shot 2015-02-12 at 22.50.27

Tah-Dah!! That’s it: Remote browsing!!

So I selected my ´phpunit.xml´ file.

Screen Shot 2015-02-12 at 22.53.51

Lastly, the dialog for the PHPUnit / Remote configuration looked like this:

Screen Shot 2015-02-12 at 22.54.14

After the click on OK I had this:

Screen Shot 2015-02-12 at 23.06.09

Simple to solve issue this one. Just refresh the Run/Debug Configurations dialog by checking and unchecking the Use alternative configuration file. And we’re ready to go:

Screen Shot 2015-02-12 at 23.09.31

Wow ! Almost there. Notice how the configuration file is working perfectly fine now.

Hm… I saw this piece of path ´/tmp/wordpress-tests-lib´ in the ´bootstrap.php´ file… right.

Screen Shot 2015-02-12 at 23.22.49

What is the value of ´WP_TESTS_DIR´ when I execute PHPUnit from the CLI?

Screen Shot 2015-02-12 at 23.26.54

If I put that in my Run/Debug Configurations dialog?

Screen Shot 2015-02-12 at 23.30.10

Alleluia, alleluia, alleluia.

Screen Shot 2015-02-12 at 23.32.30

(The backtrace is part of my stuff.)

Actually, no! It’s not working YET !!!

I can run and debug, I mean, I can click on the run and on the debug buttons and PHPStorm completes without any difference with respect to what I have when I run PHPUnit from the CLI. When I get reds in the CLI, I also get reds in PHPStorm, and when I get greens in the CLI, I also get greens in PHPStorm.

BUT there is no way to make PHPStorm see my breakpoints !! It simply ignores them.

To be fair, PHPStorm tells me something. There is an x on the breakpoint icon. Hovering, it displays this message: “File path is not mapped to any file path on server. Edit path mappings to fix the problem.” Very cryptic, or very wrong. I remember that I set my path mappings before.

Screen Shot 2015-02-13 at 1.34.29


Clicking on Validate remote environment I got this:

Screen Shot 2015-02-13 at 1.39.07

Well, not exactly, because this is what it’s supposed to look like when it’s fixed 🙂 In my case, the Deployment server was empty and its selection list was empty too, so there was no other option than to click on the top-right button.

Same as above, this is what the Deployment / Connection panel is supposed to look like when it’s fixed.

  1. The Type must be ´SFTP´.
  2. The SFTP Host and Root path must be respectively ´´ and ´/vagrant/www/wordpress-default´ which are the host name and the root directory for the ´wordpress-default´ site.
  3. Upload/download project files / Test SFTP connection… and Browse files on server / Open must work fine.
  4. I decided to set the Name equal to the SFTP Host (easier for me).
  5. User name and Password are both ´vagrant´, as per VVV setup.
  6. Autodetect does not work. For me it got ´/home/vagrant´ but that didn’t work (it didn’t make much sense either…).
  7. Last, but not least: check Save password.

And now the infamous Deployment / Mappings panel.

Screen Shot 2015-02-13 at 1.57.56

Here you could have a couple of entries: if so, remove one and make your panel look like the one above.

  1. Local path must be the path corresponding to the Root path on the Connection panel, thus ´~/dev/wp/vvv/www/wordpress-default´.
  2. Deployment path… must be the path corresponding to Local path, but considering the Root path on the Connection panel, thus ´/´.
  3. Web path… well… I think this one should be the same as the previous one, according to how all other fields are configured.

Lastly, after clicking the Validate Remote Environment / Validate button, I got:

Screen Shot 2015-02-13 at 2.22.23

Is that right? No idea, but at least it doesn’t say it’s wrong either :D. Funny, no OK button here… use Cancel.

Will it work now? NO!

There is yet another step, which (luckily?) I could find in this forum thread: PHPStorm 8 / Vagrant / Xdebug.

The crucial last point is… to tell PHPStorm to mind that whatever we were doing in the last couple of hours we really meant it. And how do we do it? Like this.

Open again the dialog for the PHPUnit / Remote configuration (I showed it above) and click on the top-right button, next to the Interpreter selection box.

Screen Shot 2015-02-13 at 1.17.54

Once again, this is how the Interpreters dialog is supposed to look like when it’s fixed. In my dialog I had selected Remote / Vagrant, but of course, the correct option is… Remote / Deployment configuration. And make sure Test connection really works.


Screen Shot 2015-02-13 at 2.38.02

After using it a few hours, here is a better configuration, to have path mappings also for debugging into the WordPress code that my testing bash file downloads and installs: ´bash bin/ test-db root root localhost latest´.

First, Deployment / Connection.

Screen Shot 2015-02-13 at 16.31.35

And then, Deployment / Mappings.

Screen Shot 2015-02-13 at 16.32.03

It works fine because my ´wordpress-default´ site is actually the latest stable version, so anything in ´/tmp/wordpress´ and in ´~/dev/wp/vvv/www/wordpress-default´ corresponds to each other one to one.

PHPUnit and Debugging

Lately I’ve been using this simple setup to print stuff to the terminal during PHPUnit runs.

     * @var bool
    public $debug_on = false;

     * @param mixed $something
    function debug_print( $something ) {
        if ( ! $this->debug_on ) {
        fwrite( STDERR, "n" . print_r( $something, true ) . "n" );

Use Case 1

Control debug printing by means of opening and closing “parentheses”:

$tested->debug_on = true;
$tested->debug_print( $stuff );
$tested->debug_on = false;

Notice that you can also control (everything or something) either from the testing or the tested code, the only difference being the use of ´$this´ instead of ´$tested´.

Use Case 2

Control debug printing by means of an automatic toggle like this one:

static $count = 0;
$this->debug_on = !$count++;
$this->debug_print( $stuff );

Same considerations as above.