In PhpStorm, there is a possibility to create Run/Debug Configurations and to run them from IDE. It allows the project participants to share common configurations using a ‘Shared’ flag in the settings. One of such operations is running unit tests in the course of development. Let’s discuss how to fine-tune this process by means of Docker.
Integration with PhpStorm Gladly, since PhpStorm is a very powerful tool, it supports integration with docker, which can be then used, among other things, to automatically run tests inside a container. From this point, I'm going to explain the process, assuming you have already installed docker in your system. PHPUnit; and; Your IDE or editor of choice. Whenever I write PHP code, it’s reasonably safe to say that I use PhpStorm. So that’s why, in this article, I’m going to show you how to integrate Xdebug, PHPUnit, and PhpStorm. On Small Caveat. This article doesn’t cover debugging web-based applications with PhpStorm, but smaller code libraries. I have server with docker on it. On the server i have compose.yaml with services i need for my app. And now if i want to run a test I can go t. Tutorial to set up PhpStorm for local PHP web development using Docker containers, Apache webserver, MySQL database, and PHPUnit testing framework for your P. Fix Xdebug on PhpStorm when run from a Docker container. Long story short: There is a bug in the networking setup of Docker for Win that makes PhpStorm use the wrong remotehost when it starts a debugging session. When you take a look at the 'Console' panel at the bottom of the IDE, you should see something like this.
There is a plugin PHPUnit Code Coverage which is used to display the code coverage with the PhpStorm tests. PhpUnit can be run with the options for generating code coverage report. This report will contain the information about the number of calls to each operator during tests execution. Using these statistics, we can calculate the percentage of the test code coverage since if there are operators in the file which have never been called during the tests, then, this piece of code is not covered by tests. That’s what the plugin in the form of a table with file and directory navigation shows. The plugin also can highlight in green or red the lines in your files which, correspondingly, are covered or not covered by tests:
For this plugin to work correctly in PhpStorm with PHP CLI configured from the Docker container, a range of additional actions should be taken.
First, so far, the work with the already running containers has not been implemented correctly yet. It is a well-known drawback which is discussed here. There is an issue where users suggest possible solutions, and there is also an issue where the fix for this problem is being planned. I recommend you to subscribe to them to remain informed. Briefly, the matter is that when you set up running of Run Configuration from Docker, PhpStorm restarts the container with PHP any time the script is performed in it, and after that, the container is stopped. It can be observed from the results of test running from PhpStorm:
This approach makes permanent development impossible. When you write tests and features in IDE and then run tests, and after that switch to the browser and test the feature manually, you need to restart PHP container by hand because PhpStorm stops it after running your console script from the Run/Debug menu. To evade this side effect till JetBrains developers solve it, the community has worked out the easiest solution. You need to create another PHP container which will be used solely for Run/Debug Configurations in PhpStorm. IDE will run it, stop it or whatever. At the same time, your major PHP container will not be killed, and you will be able to run your code from the web browser (or any other client for HTTP calls). The configuration, in this case, looks like this:
docker-compose.yml
Note.jekakm/php71-core:201807161 image is our studio image for PHP container. You may use any other image for PHP as a basis.
php_cli container should be inherited from the PHP container or be its copy. Depending on the exact PHP image and exact platform, the root access within the container is necessary for the correct work of the code coverage plugin. We have solved this problem by adding an additional instruction in our image for the console PHP. If, during the code coverage generation, PhpStorm notifies you that it can’t get access to a certain category, then, you need to add into the ./docker-configs/php-image/Dockerfile file the following:
Phpstorm Docker Compose
./docker-configs/php-image/Dockerfile
Now, we need to set up and choose PHP Server from Docker for our scripts from Run/Debug. For this purpose, in the PhpStorm’s settings, choose «Languages & Frameworks →PHP→CLI Interpreter» and add a new server. Also, tick the «Visible only for this project» option since for every project you should have a separate docker-compose.yml to avoid inter-project connection sharing in PhpStorm. Choose configuration for Docker Composer and then, in the Service drop-down menu, choose the one we have created, php_cli:
You also need to go to Languages & Frameworks → PHP → Test Frameworks settings and create a new configuration for PHPUnit by Remote Interpreter. In the drop-down list of interpreters, choose the one we set up earlier, PHP 7.1 Docker Compose. You can configure the PHPUnit settings by default. Since the tests are run from Docker, we need to specify the paths to the files regarding their location in the container. In our case, the project is in the /app folder, that’s why the path to the autoloader is specified as /app/vendor/autoload.php, and the path to the configuration file is /app/phpunit.xml.dist. It is important to specify this path correctly because there won’t be a clue from PhpStorm.
We should also mention that for PhpStorm to process the file with coverage result correctly, you need to specify the path to the files correctly. For this, in the Test Frameworks settings for the configuration setted up for Docker, you will have to add a new rule into the Path mappings. The local path should refer to the directory where the source code is stored locally. In the example, it is home/user/sites/project_name. Remote Path is a path to the root of your project in the Docker container. In our example it is /app:
This should be done because the code coverage report stores the paths to the files which were processed by PHPUnit. The report generated in Docker, correspondingly, preserves the paths to the files regarding their location in the container. And when the file which is mentioned in the report is open in PhpStorm, the PhpStorm highlights line coverage in it. On the contrast, if the local file path and the report file path do not correspond, the PhpStorm will not understand that the Docker container path complies with the local path and the file should be highlighted.
After all setups, we reassemble containers, run them and work with a project in the browser. Simultaneously we run tests in PhpStorm. They are performed in the php_cli container and do not affect the PHP container. The deployment of a separate container to run console utilities is not limited by PHPUnit. Now that you have a configured interpreter from the php_cli container, you can create other Run/Debug Configurations in PhpStorm, for example, any PHP Script which will also be run in this short-lived container. Thus you can see the implementation result immediately in IDE without having to switch to the terminal and type in the command manually. It also allows the optimization of the development process since in Run/Debug Configurations you can assign dedicated hotkeys in PhpStorm so that the running of the routine tasks will be confined to the shortcut on your keyboard.
Another possible source of problems with Docker inside PhpStorm is a docker-compose utility. Don’t forget to update it. I myself encountered the situation when PhpStorm didn’t want to run it because I had a too early version installed on my computer. The update to the current version solved this problem. You can check for the current version here, and you can find the guidelines for the docker-compose update here.
P.S. If JetBrains developers eventually improve the behavior of the docker-compose utility in their IDE (well, this issue is urgent not only for PhpStorm), there will no longer be any need for the approach described.
FeaturesPhpStorm 2016.3 gives a much easier way to configure a Docker remote interpreter, with configuration done from an extra config option in the Interpreters pane of the IDE.
Phpstorm Phpunit Docker Free
It’s previously been possible to work with a container based remote interpreter within PhpStorm, but the configuration was painful using the SSH settings, and it didn’t play well with all of the IDE’s features. In PhpStorm 2016.3, Docker interpreters become a first-class citizen.
Firstly, you’ll need to have a valid Docker configuration. If you are running your host on OSX and using Docker for Mac (as opposed to Docker Machine) then you’ll need to install an extra piece of software — you can find the instructions here. Once you have your Docker configuration setup, we can add the remote interpreter.
We can add a new interpreter from the preferences pane, by selecting Languages & Frameworks, then PHP, and clicking the […] button next to the interpreter drop down. Next, we click the [+] button to add a new interpreter and select Remote.
You can see that the new Docker option added. Once we’ve selected that, we need to pick the Docker configuration (it’s already configured it as mentioned above), and then the image name we wish to use for the container that has our PHP install, plus the path on the container to find the PHP executable.
Phpstorm Phpunit Docker Download
Note: While just `php` will work fine in some cases, there have been reports that the full path to the PHP executable is needed. You can find this out by running the docker command `docker-compose run php which php` in the directory that your `docker-compose.yml` file is located where `php` is the container name. If you use another docker tool, substitute the `docker-compose` for that tool’s name.
Once we’ve clicked OK, you should see the new interpreter configured correctly and available to select. It’s worth giving it a more descriptive name (and I make it Visible for only this project as containers are usually project based).
Once PhpStorm has picked up your Docker settings, you’ll see the PHP version updating as PhpStorm runs some commands on the container to infer the configuration. Now that the remote interpreter is specified, we can also add the local path on the container to the Xdebug file so that we can step debug our command line scripts using the Xdebug On-Demand tool.
Now that we have the remote interpreter configured, we can use it as usual in any of the places we’d typically set an interpreter, including our test runner (PHPUnit, PhpSpec, Behat), code quality tools (PHPCS and PHPMD), and as previously mentioned, debugging. Let’s configure our PHPUnit test suite to run using this newly supplied Docker container.
We need to tell PhpStorm which interpreter and how to find PHPUnit for this project, we can do that in the PHPUnit settings pane, found under Languages & Frameworks, PHP, PHPUnit. You may already have a configuration here (if you’ve previously been running the unit tests locally, for example), but we need to create a new configuration by clicking the [+] and selecting By Remote Interpreter and then picking the interpreter we configured earlier.
Because PHPUnit is installed here using composer, I can just tell PhpStorm where to find the Composer autoloader as a local path on the container. Notice how we have a mapping from the project root to `/opt/project`. Now we can click OK, and add a run configuration for PHPUnit by clicking the Edit Configurations option from the Run dropdown menu. We can add a new configuration using the [+] button, and selecting PHPUnit.
I like to use the configuration file to define test scope, so I’ve chosen Defined in the configuration file and used an alternate configuration file than the default, but you can do whatever you usually do here. Note that paths in this dialogue are relative to the host machine — not the container. Now, we can save the settings and run the test runner using the green play icon. Hopefully, everything is green.
Docker is an incredible innovation in using containers for development and deployment, and hopefully, these changes in PhpStorm open the door to being able to quickly develop and test your codebase against multiple versions of PHP easily. Try it yourself, and let us know what you think.
— Gary and the PhpStorm Team