By Artem Henvald In , there is a possibility to create 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 . PhpStorm Run/Debug Configurations Docker There is a plugin 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: PHPUnit Code Coverage 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 . There is an where users suggest possible solutions, and there is also an 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 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: here issue issue Run Configuration 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 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 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: Run/Debug Run/Debug Configurations docker-compose.yml container should be inherited from the 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 file the following: php_cli PHP ./docker-configs/php-image/Dockerfile ./docker-configs/php-image/Dockerfile Now, we need to set up and choose PHP Server from Docker for our scripts from . 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, : Run/Debug php_cli You also need to go to settings and create a new configuration for . In the drop-down list of interpreters, choose the one we set up earlier, PHP 7.1 Docker Compose. You can configure the 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 folder, that’s why the path to the autoloader is specified as , and the path to the configuration file is . It is important to specify this path correctly because there won’t be a clue from PhpStorm. Languages & Frameworks → PHP → Test Frameworks PHPUnit by Remote Interpreter PHPUnit /app /app/vendor/autoload.php /app/phpunit.xml.dist 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 T_est Frameworks_ settings for the configuration setted up for Docker, you will have to add a new rule into the . The local path should refer to the directory where the source code is stored locally. In the example, it is . is a path to the root of your project in the Docker container. In our example it is : Path mappings home/user/sites/project_name Remote Path /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 container and do not affect the 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 container, you can create other 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 you can assign dedicated hotkeys in PhpStorm so that the running of the routine tasks will be confined to the shortcut on your keyboard. php_cli PHP php_cli Run/Debug Configurations Run/Debug Configurations Another possible source of problems with Docker inside PhpStorm is a 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 , and you can find the guidelines for the update . docker-compose here docker-compose 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. Originally published at stfalcon.com .

Routine

UX Practices from Best Travel Sites: Functionality and Usability

Too Long; Didn't Read

Make resilience your competitive advantage

Running PHPUnit Tests with Code Coverage in PHPStorm When Working in Docker

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

UX Practices from Best Travel Sites: Functionality and Usability

Why Dockerizing Applications is the Key to Building Scalable Software

10 Free Courses to Learn Docker for Programmers and DevOps Engineers

10 Free Courses to learn Docker and DevOps for Programmers and Software Developers

10 DevOps Conferences You Should Be Attending in 2020

UX Practices from Best Travel Sites: Functionality and Usability

Why Dockerizing Applications is the Key to Building Scalable Software

10 Free Courses to Learn Docker for Programmers and DevOps Engineers

10 Free Courses to learn Docker and DevOps for Programmers and Software Developers

10 DevOps Conferences You Should Be Attending in 2020

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps