Además, podremos ver un caso típico de testing por intervalos, donde debemos comprobar que cada intervalo produce la salida correcta.

The post Tests Unitarios en Drupal. Parte 2: Sujetos de test con dependencias appeared first on Víctor Dorado.

En este vídeo veremos, de forma muy resumida, cómo se puede crear un test unitario en Drupal. Crearemos un servicio muy simple y un test que compruebe que el servicio se comporta como esperamos. Además, podremos apreciar, en primera persona, las ventajas de programar con TDD (Test Driven Development).

The post Tests unitarios en Drupal con PHPUnit y PHPStorm appeared first on Víctor Dorado.

However, adhering to agreed-upon rules isn’t always easy. With many conventions to remember, we need tools to assist us. This is where our quality tools come in. They provide a powerful toolkit to ensure that our coding standards and style agreements are met. Furthermore, we can configure PHPStorm to use these tools, creating an integrated in-editor coding experience.

In this article we will be working on a Drupal project, but the process is applicable to any project type, as long as we will be using standard npm/yarn and Composer package management to get the tools.

Installing PHP_CodeSniffer

We will install it with Composer, as usual for many other PHP packages. We will also use a handy tool to ease the installation process.

#ddev composer require --dev squizlabs/php_codesniffer dealerdirect/phpcodesniffer-composer-installer drupal/coder

After that, as the documentation states (https://packagist.org/packages/dealerdirect/phpcodesniffer-composer-installer) we must ensure the following config is present in our composer.json:

{
    "config": {
        "allow-plugins": {
            "dealerdirect/phpcodesniffer-composer-installer": true
        }
    }
}

If we are using Composer < 2.2 it won’t and we will have to add it with the following command:

# composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true

After that, we will let the magic happen:

# composer install

Now, we can execute the phpcs command inside our DDEV web container:

# ddev exec phpcs --version
Registering sniffs in the PEAR standard... DONE (28 sniffs registered)
PHP_CodeSniffer version 3.10.1 (stable) by Squiz and PHPCSStandards

Note that PHP_CodeSniffer says something about a “standard”. PHP_CodeSniffer checks our code against one of various possible “standards”, and there are some of them bundled by default with it. The default standard that will be used is the “PEAR” one.

But, for a Drupal project (a website, a theme, a contrib module… etc.), we must use a special crafted standard called “Drupal”, that has all the Drupal community-agreed coding standards. Thanks to our previously installed dealerdirect/phpcodesniffer-composer-installer, we can see that the standards “Drupal” and “DrupalPractice” are installed:

# ddev exec phpcs -i
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, Drupal, DrupalPractice, VariableAnalysis and SlevomatCodingStandard

(DrupalPractice is a more exhaustive standard that checks not only the coding style used, but also some best practices for Drupal development).

In this article, we will focus in the use of PHPCS through the UI, that is what will make a more “realtime” development experience. Using phpcs from the command line is harder, and is often only used by cli scripts, like in CI environment QA tests, or s Git precommit hook in a local development environment.

Integrating PHP_CodeSniffer with PHPStorm

PHPStorm has friendly configuration dialogs for some popular quality tools, and one of them is PHPCS.

Is highly recommended executing PHPCS inside our DDEV container, in order to keep consistency with our project’s PHP version and configuration instead of relying on our own machine config. To do so, first we must have a PHPStorm “DDEV” PHP interpreter (check my previous article PHPUnit up and running with Drupal, DDEV and PHPStorm to know how to accomplish it).

Then, go to Settings, under the “PHP – Quality Tools” section, and open the first accordion, setting its configuration and options as follows:

Notice that Drupal Core uses a different more relaxed standard. If you are going to develop for core you should set the coding standard to “Custom” and point to your project’s <drupal-root>/core/phpcs.xml.dist

You can also configure some additional inspection settings in the “Editor – Inspections” menu:

Once configured, edit any file and PHPStorm will automatically execute PHPCS, showing the warnings and errors in that file.

Conclusion

Maintaining a consistent code style in our projects is made easier with these supportive tools. Including them in every developer’s toolkit is highly beneficial.

The post Improve your code quality from PHPStorm with PHP_CodeSniffer appeared first on Víctor Dorado.

First step: enabling DDEV integration plugin for PHPStorm

DDEV has a PHPStorm plugin that eases a lot working with DDEV. One of the great things DDEV’s plugin does is creating a CLI interpreter that executes PHP code inside the web container. This will be the cornerstone of our setup.

Setting DDEV as the project’s CLI interpreter and the Test framework interpreter

Under Settings -> PHP section, we can now select the DDEV CLI interpreter:

If you don’t see the interpreter, check that you have a Docker connection added in Build, Execution, Deployment -> Docker:

And check that “Use Compose V2” is enabled under the Tools subsection:

Now, we must go to PHP -> Test Frameworks and add a new one that uses the DDEV CLI interpreter:

We must also set a custom Default configuration file named phpunit.xml and located in our project’s root directory. DDEV’s CLI interpreter runs inside the web docker container, so we must set the path as it’s seen inside the container: /var/www/html/phpunit.xml. (this file doesn’t exist yet, we will create it later).

Now, we have to tell PHPStorm to run this project’s tests with this new test framework. Go to Run -> Edit configurations menu and clear any configuration you may find here.

Then, click on Edit configuration templates… -> PHPUnit and set DDEV as the Command Line Interpreter:

Creating project’s PHPUnit configuration file

Copy core’s PHPUnit configuration file /web/core/phpunit.xml.dist to /phpunit.xml, and edit it as follows:

<?xml version="1.0" encoding="UTF-8"?>

<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         bootstrap="web/core/tests/bootstrap.php"
         colors="true"
         beStrictAboutTestsThatDoNotTestAnything="true"
         beStrictAboutOutputDuringTests="true"
         beStrictAboutChangesToGlobalState="true"
         failOnWarning="true"
         printerClass="\Drupal\Tests\Listeners\HtmlOutputPrinter"
         cacheResult="false"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/9.3/phpunit.xsd">
  <php>
    <ini name="error_reporting" value="32767"/> <!-- 32767 = E_ALL. -->
    <ini name="memory_limit" value="-1"/>
    <env name="SIMPLETEST_BASE_URL" value="http://my-project.ddev.site"/>
    <env name="SIMPLETEST_DB" value="mysql://db:db@db:3306/test"/>
    <env name="BROWSERTEST_OUTPUT_DIRECTORY" value=""/>
<!--    <env name="SYMFONY_DEPRECATIONS_HELPER" value="weak"/>-->
  </php>

  <testsuites>
    <testsuite name="unit">
      <directory>web/modules/custom/*/tests/src/Unit/</directory>
    </testsuite>
    <testsuite name="kernel">
      <directory>web/modules/custom/*/tests/src/Kernel/</directory>
    </testsuite>
    <testsuite name="functional">
      <directory>web/modules/custom/*/tests/src/Functional/</directory>
    </testsuite>
    <testsuite name="functional-javascript">
      <directory>web/modules/custom/*/tests/src/FunctionalJavascript/</directory>
    </testsuite>
  </testsuites>

  <listeners>
    <listener class="\Drupal\Tests\Listeners\DrupalListener">
    </listener>
    <!-- The Symfony deprecation listener has to come after the Drupal listener -->
    <listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener">
    </listener>
  </listeners>

  <coverage>
    <include>
      <directory suffix=".php">web/modules/custom/*/src</directory>
    </include>
  </coverage>

</phpunit>

These are all the customizations that have been made:

1. Adjust the boostrap path to core’s bootstrap

bootstrap="web/core/tests/bootstrap.php"

2. Set site URL and database connection details (for Kernel, Functional… etc. tests). Note that PHPUnit will be executed inside the web container, so we must set “db” and port 3306 as our database host, as it is seen from the web container. We also set the testing database name to “test”, that is the convention.

<env name="SIMPLETEST_BASE_URL" value="https://my-project.ddev.site"/>
<env name="SIMPLETEST_DB" value="mysql://db:db@db:3306/test"/>

3. Finally, we adjust all test suites to only execute tests from our custom modules by default, if we execute phpunit without file parameters nor filters.

<testsuite name="unit">
  <directory>web/modules/custom/*/tests/src/Unit/</directory>
</testsuite>
<testsuite name="kernel">
  <directory>web/modules/custom/*/tests/src/Kernel/</directory>
</testsuite>
...

Installing PHPUnit

As simple as installing these packages with Composer

# ddev composer require --dev \
  phpunit/phpunit \
  phpspec/prophecy-phpunit \
  symfony/phpunit-bridge \
  dmore/chrome-mink-driver \
  behat/mink-browserkit-driver \
  behat/mink-selenium2-driver \
  mikey179/vfsstream

• phpunit/phpunit – The PHPUnit core package.
• phpspec/prophecy-phpunit – The Prophecy mocking system. In a lot of tests it is used instead of PHPUnit Mock Object Framework, the PHPUnit standard.
• symfony/phpunit-bridge – Bridges the gap between Symfony and PHPUnit.
• dmore/chrome-mink-driver – Required for some Kernel nad Functional tests.
• behat/mink-browserkit-driver – Required for some Functional tests.
• mikey179/vfsstream – Some tests make use of this virtual filesystem mocker.

Configuring DDEV Selenium Standalone Chrome

This config is necessary to execute Javascript and FunctionalJavascript Drupal tests. PHPUnit needs a headless Chromium browser to control and to send commands to. That’s what this DDEV addon provides.

Follow the instructions in https://github.com/ddev/ddev-selenium-standalone-chrome:

# ddev get ddev/ddev-selenium-standalone-chrome

Then, update your .ddev/config.selenium-standalone-chrome.yaml and set the local domain for your DDEV project, making sure you set it as http:// and not https:// (I got an “invalid cookie domain” error when I did).

#ddev-generated  <- REMOVE THIS LINE

...

- SIMPLETEST_BASE_URL=http://my-project.ddev.site

...

- DRUPAL_TEST_BASE_URL=http://my-project.ddev.site

...

- DTT_BASE_URL=http://my-project.ddev.site

Then, restart DDEV:

# ddev restart

Executing tests from the command line

If we want being able to execute our tests easily from outside the web container, we must create the file /.ddev/commands/web/phpunit with this content:

#!/bin/bash

phpunit "$@"

And now, outside the web container, we can do:

# ddev phpunit
# ddev phpunit --testsuite <name>

Executing tests from PHPStorm

From PHPStorm’s interface, we can go to any test case class and use the GUI to run its tests, either all at once or one by one, simply clicking on the run icons next to the class and test method definitions:

We can even right click on any directory in the project’s explorer and click on “Run (tests PHPUnit)” and all tests in that directory will be executed. This is very convenient when we want to debug only a test method or execute only one type of tests inside a module, for example.

Conclusion

Getting PHPStorm, DDEV, Drupal and PHPUnit to work together is not a trivial task. Although DDEV’s PHPStorm plugin eases a bit the task, we have yet to wire all the things correctly.

The post PHPUnit up and running with Drupal, DDEV and PHPStorm appeared first on Víctor Dorado.

If you also add DDEV and its docker containers to the mix, it’s not easy to get all pieces working, without a proper recipe. This article aims to be that recipe.

Preparing DDEV’s web container

DDEV automatically adds two environment variables to its .ddev-docker-compose-base.yaml file:

PHP_IDE_CONFIG=serverName=${DDEV_SITENAME}.${DDEV_TLD}
DRUSH_ALLOW_XDEBUG=1

Mind the serverName because we will need it later, when configuring a server in PHPStorm.

Now, we must config the Xdebug PHP extension. Create a new directory .ddev/php/ and create a file called xdebug.ini inside it, with this content.

xdebug.client_port = 9000
xdebug.idekey = PHPSTORM
xdebug.mode = develop,debug
xdebug.start_with_request = yes

I like to set xdebug.start_with_request=yes and turn on and off the web contaniner’s xdebug PHP extension with ddev xdebug on and ddev xdebug off. You could set xdebug.start_with_request=no and play with a browser switch like Xdebug Helper, but this won’t have effect on drush commands.

After that, we have to restart DDEV’s web container:

# ddev restart

Configuring PHPStorm

Now, we must create a new PHP server under Settings -> PHP -> Servers. Recall the server name we saw in DDEV’s config: it was ${DDEV_SITENAME}.${DDEV_TLD}, that translates to my-project.ddev.site if your DDEV project is named my-project.

We need to set path mappings for the webserver docroot directory. A path mapping “maps” a real directory path in your filesystem with a directory inside the DDEV docker web container. In our case, a DDEV drupal project has its web server’s document root in /var/www/html/web, so we have to set this mapping:

• /path/to/your/project/web -> /var/www/html/web

However, I recommend also adding this mapping to be able to debug vendor code.

• /path/to/your/project/vendor -> /var/www/html/vendor

With these mappings, PHPStorm now knows how to map between the same file as it’s seen inside/outside DDEV’s web container.

After that, to be sure everything is ok, I recommend checking and configuring the Xdebug installation under PHP -> Debug:

First, click on the “Validate” link:

In the next screen configure the docroot directory as it’s seen by PHPStorm (your real machine path to the web directory inside your project directory) and the URL where the project’s docroot will be accesible. Then, click on “Validate”.

I strongly recommend unchecking these two “Force break” checkboxes, because we don’t want the execution to be paused if we don’t set or don’t reach a breakpoint. I remember myself waiting a drush command to finish unaware that the execution was paused, because of this.

So far, we have configured DDEV and PHPStorm to “connect” between them and our next step will be to set a breakpoint. For example, we can break on the handle() call that Drupal\Core\DrupalKernel class does on every page load.

Click next to the line number and a red dot will appear. This is our breakpoint. The PHP execution will stop here until we let it continue.

Remember to enable xdebug PHP extension on DDEV’s web container with

# ddev xdebug on

And to tell PHPStorm to listen to incoming debug connections with the icon.

Now, reload any page in your browser and you will view a system notification letting you know that PHPStorm requires your attention. Go for it and you will see the breakpoint’s line highlighted and a panel where you can explore all the variables in it’s scope.

You can browse the variables panel and deep dive into the tree structures. This is VERY useful, specially when debugging a framework like Drupal that has many nesting levels on its variables.

You can also select any piece of code, right click on it and click on “Evaluate expression” and you could test it inside that paused execution state. You can even write directly your own expressions.

You can continue the execution step-by-step (step over, F8), even traveling inside method calls (step into, F7), or continue the execution until the next breakpoint (or the same breakpoint if it’s reached again)

Conclusion

Debugging goes next level when it’s done with a tool like Xdebug and through a debugging GUI like PHPStorm has.

The post Debug your Drupal code with PHPStorm, DDEV and Xdebug appeared first on Víctor Dorado.