Docker を使ってローカルで WordPress plugin の PHPUnit を実行してみよう

WordPress plugin を PHPUnit でテストするためには、
WordPress, PHPUnit のインストールの他に Subversion 、
そして MySQL 等のデータベースが必要になります。
この環境構築には時間がかかります。
この記事では Docker を利用して環境構築の手順をスキップします。

なお、より効率的に開発を行うために、
この記事で紹介している方法よりも
Visual Studio Code を組み合わせた方法をおすすめします。

ローカルでの PHPUnit 実行方法
トラブルシューティング
- Fatal error: require(): Failed opening required '/plugin/directoryname.php' (include_path='.:/usr/local/lib/php') in /plugin/tests/bootstrap.php on line 26
  - 対応
  - 解説
- ERROR: Referenced sniff "WordPress.VIP" does not exist
  - 対応
  - 解説

ローカルでの PHPUnit 実行方法

手順

1. docker-compose.yml を準備します

以下の内容で準備します:

---
version: '3.7'
services:
  database:
    container_name: database
    environment:
      MYSQL_ROOT_PASSWORD: examplepass
    image: mysql:5.7

  phpunit:
    command:
      - bash
    container_name: phpunit
    depends_on:
      - database
    environment:
      DATABASE_PASSWORD: examplepass
    image: futureys/phpunit-wordpress-plugin
    stdin_open: true
    tty: true
    volumes:
      - ${PATH_TO_PLUGIN_DIRECTORY}:/plugin

2. テスト対象の WordPress plugin ディレクトリーへのパスを設定します

手順 1. で作成した docker-compose.yml の
“${PATH_TO_PLUGIN_DIRECTORY}” を直接書き換えます。

もしくは、
docker-compose.yml と同じディレクトリーに .env ファイルを
以下の内容で作成します:

PATH_TO_PLUGIN_DIRECTORY=path/to/plugin-directory

どちらの方法も、絶対パスでも相対パスでも記述できます。

3. コンテナを起動します

$ docker-compose run phpunit

するとコンテナが起動し、
これ以降に実行するコマンドはコンテナ内で実行している状態になります。

4. 適宜 PHPUnit または PHP_CodeSniffer を実行します

この状態で、PHPUnit や PHP_CodeSniffer が実行し放題になります。
PHPUnit を実行する場合は以下のコマンドを実行します:

$ phpunit

PHP_CodeSniffer を実行する場合は以下のコマンドを実行します:

$ phpcs

利用が完了したら、コンテナから退出し
コンテナとネットワークを片付けましょう。

$ exit
$ docker-compose down

トラブルシューティング

Fatal error: require(): Failed opening required ‘/plugin/directoryname.php’ (include_path=’.:/usr/local/lib/php’) in /plugin/tests/bootstrap.php on line 26

対応

tests/bootstrap.php の 26 行目は以下のようになっています。
例:

	require dirname( dirname( __FILE__ ) ) . '/plugin-directory-name.php';

上記の例の “/plugin-directory-name.php” の部分は、
初期状態では WordPress plugin のディレクトリー名と同じになっていますが、
これをテスト対象の WordPress plugin のメインとなる PHP ファイルに
変更します。

解説

WordPress plugin のメインとなる PHP ファイルは
ある程度自由に名前を付けることができますが、
テストのためのファイルを生成する処理では
ディレクトリー名と同名の前提でファイルが生成されます。

参考:
WordPress plugin のメインとなる PHP ファイルを選択する処理
WordPress/plugin.php at master · WordPress/WordPress
テストのためのファイルを生成する処理
scaffold-command/plugin-bootstrap.mustache at master · wp-cli/scaffold-command
scaffold-command/Scaffold_Command.php at master · wp-cli/scaffold-command

ERROR: Referenced sniff “WordPress.VIP” does not exist

対応

.phpcs.xml.dist を以下のように書き換えます:

-		<exclude name="WordPress.VIP"/>
+		<exclude name="WordPress-VIP-Go"/>

解説

“WordPress.VIP” というルールセットは現在存在せず、
代わりに “WordPress-VIP-Go” というルールセットを用いるべきであるようです。

GitHub 上の WordPress コーディング標準の README.md に、次のような記述があります。

Note: The WPCS package used to include a WordPress-VIP ruleset and associated sniffs, prior to WPCS 2.0.0. The WordPress-VIP ruleset was originally intended to aid with the WordPress.com VIP coding requirements, but has been superseded. It is recommended to use the official VIP coding standards ruleset instead for checking code against the VIP platform requirements.
GitHub 上の WordPress コーディング標準の README.md より

これは、大体以下のような意味です。

注:
WPCS パッケージには、
以前は WordPress-VIP ルールセットが含まれていて、
WPCS 2.0.0 より前の (コーディング規約違反の) 探知機能に
関連付けられていました。

WordPress-VIP ルールセットは、もともと
WordPress.com VIP コーディング要件を支援することを
目的としていましたが、置き換えられました。

VIP プラットフォームの要件に照らしてコードをチェックする代わりに、
公式の VIP コーディング標準ルールセットを使用することをお勧めします。