Lorsque CloverCoverage échoue et passe simultanément

J’ai parlé des avantages de l’utilisation de GrumPHP dans les articles précédents. L’un des outils que nous avons utilisés dans des projets au cours de la dernière année ou plus est Clover.

Photo de Quentin REY sur Unsplash

Quelque temps entre le moment où nous avons commencé à l’utiliser et cette semaine, il échouait toujours à s’exécuter à chaque fois sur ma machine locale, mais pas sur la machine sur laquelle nous déployions notre code.

Et non, ce n’était pas parce qu’il y avait des directives ou des commentaires incorrects dans les tests unitaires et ce n’était pas parce que PHPUnit était mal configuré (il exécutait tous les tests et les signalait comme prévu).

Alors qu’est-ce qui donne ?

Lorsque CloverCoverage échoue

La version TL; DR de ceci :

Vous devez avoir Xdebug correctement installé car CloverCoverage nécessite un pilote – c’est-à-dire Xdebug – pour s’exécuter correctement. Le problème est que si vous utilisez Homebrew, vous ne pouvez pas l’installer comme nous le pouvions à un moment donné.

Le reste de cet article vous expliquera comment installer Xdebug, le configurer correctement dans votre configuration PHP, configurer correctement votre configuration PHPUnit, puis vérifier que tout est vérifié afin que la prochaine fois que vous exécuterez GrumPHP, vous devriez obtenir toutes les coches vertes. .

Et, en prime, la prochaine fois que vous exécuterez PHPUnit, vous devriez obtenir un rapport attrayant pour accompagner cela. Voici ce que vous devez faire.

Tout d’abord, notez que cela repose sur l’idée que vous êtes :

• en utilisant Homebrew,
• avoir installé PHPUnit,
• avoir PHP 7.1 installé (j’utilise PHP 7.1.19 au moment d’écrire ce post),
• Clover ne s’exécute pas correctement.

Pour vérifier certaines choses, lancez la commande suivante dans le terminal :

Assurez-vous que vous utilisez au moins PHPUnit 7.1.4.

Ensuite, vérifiez votre version PHP :

Et assurez-vous que vous exécutez au moins PHP 7.1.19 (votre sortie ne ressemble pas exactement à la mienne, en particulier en ce qui concerne Xdebug, mais c’est le but de ce point).

À ce stade, nous sommes prêts à installer Xdebug et à commencer à apporter les modifications de configuration nécessaires.

1 Installer Xdebug

La raison pour laquelle nous devons installer Xdebug différemment qu’auparavant est qu’il n’est plus pris en charge par Homebrew. Pas de soucis cependant, car il est tout aussi facile à installer via Pecl.

Pour l’installer, saisissez la commande suivante dans votre terminal :

Vous devriez alors voir un message indiquant qu’il a été installé et que l’extension a été ajoutée à votre fichier de configuration PHP. D’après mon expérience, Pecl n’obtient pas la dernière étape correctement.

2 Localisez le binaire Xdebug sur le disque

Pour remédier à cela, nous devons :

1. localiser le chemin complet de l’extension Xdebug,
2. placez le chemin complet vers l’extension dans notre fichier de configuration PHP

Pour trouver les chemins dans lesquels Xdebug peut résider, utilisez la commande suivante :

Vous pouvez obtenir plusieurs chemins retournés (idéalement, cependant, vous ne devriez en obtenir qu’un). Si vous en obtenez plusieurs, recherchez celui installé dans le chemin contenant le répertoire Pecl. Cela ressemblera probablement à quelque chose comme ça :

/usr/local/lib/php/pecl/20160303/xdebug.so

Une fois que vous obtenez une liste de tous les endroits où Xdebug.so est installé, copiez le chemin du fichier afin que nous puissions configurer PHP pour le référencer et l’utiliser correctement.

3 Mettre à jour la configuration de PHP

Ensuite, nous devons mettre à jour la configuration de PHP. Cela est facile car nous avons simplement besoin d’ajouter une seule ligne au fichier PHP.ini. Bien sûr, si vous avez plusieurs versions de PHP en cours d’exécution, assurez-vous de l’ajouter au bon fichier de configuration dépendra de la version de PHP que vous utilisez.

Si vous avez plusieurs versions de PHP en cours d’exécution sur votre machine, vous aurez alors plusieurs versions du fichier de configuration PHP. Si vous avez une seule version installée, vous aurez un seul  fichier php.ini.

Ceci est généralement situé dans /usr/local/etc/php/7.1/ en tant que php.ini  si vous utilisez PHP 7.1 mais votre emplacement peut être légèrement différent. Mais l’étape suivante reste la même.

Une fois que vous avez fait cela, assurez-vous d’ajouter la ligne suivante au  fichier php.ini . Cela peut être n’importe où dans le fichier, vraiment, mais rappelez-vous que vous devez inclure le chemin complet vers Xdebug.so. Le fichier doit donc inclure cette ligne :

zend_extension="/usr/local/lib/php/pecl/20160303/xdebug.so"

A partir de là, tout devrait fonctionner. Vous pouvez le vérifier en exécutant :

Et puis vous devriez voir le message suivant :

PHP 7.1.19 (cli) (construit : 25 juin 2018 10:42:21) (NTS)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2 .6.0, Copyright (c) 2002-2018, par Derick Rethans
avec Zend OPcache v7.1.19, Copyright (c) 1999-2018, par Zend Technologies

Notez la quatrième ligne qui inclut une remarque sur Xdebug. Si vous voyez cela, alors vous êtes prêt à partir.

4 Configuration de PHPUnit

À ce stade, la dernière chose que vous devez faire est de vous assurer que votre fichier phpunit.xml est correctement configuré. Voici un exemple simple de ce à quoi ressemble le mien (cela inclut également la prise en charge de Clover):

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

<!-- http://phpunit.de/manual/4.1/en/appendixes.configuration.html -->
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.1/phpunit.xsd"
         bootstrap="./tests/bootstrap.php"
         backupGlobals="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
>
  <testsuites>
    <testsuite name="Plugin">
      <directory>./tests</directory>
      <exclude>./tests/phpunit</exclude>
      <exclude>./src/WordPress/*.php</exclude>
    </testsuite>
  </testsuites>

  <logging>
    <log type="coverage-clover" target="./coverage-report/coverage.xml"></log>
    <log type="coverage-html" target="coverage-report" lowUpperBound="30" highLowerBound="80"></log>
    <log type="coverage-text" target="php://stdout" showUncoveredFiles="false"></log>
  </logging>

  <filter>
    <whitelist>
      <directory>./src</directory>
    </whitelist>
  </filter>
</phpunit>

Ensuite, vous pouvez exécuter manuellement PHPUnit et voir une belle sortie de couverture de code.

Ou vous pouvez exécuter GrumPHP pour voir la coche verte continue (en supposant que vos tests se situent dans la plage que vous avez définie dans grump.yml ).

Le résultat final

Bien que cela puisse sembler beaucoup d’étapes (et je suppose que c’est le cas), il ne faut pas longtemps pour que cette configuration fonctionne correctement. Espérons que la procédure pas à pas ci-dessus vous fera gagner un peu de temps lorsque vous travaillez avec PHP, PHPUnit, etc. lorsque CloverCoverage échoue (et réussit simultanément lors d’un déploiement continu).

J’écris actuellement un livre électronique (avec une variété d’autres contenus premium). Si vous êtes intéressé, regardez ce que vous obtenez.