【PHP版】CI（継続的インテグレーション）ツール導入ガイド：第4回さまざまなジョブ (2)

第2回さまざまなタスク「CIの実行中に処理されるジョブ」についての概要を、第3回さまざまなジョブ(1) CIのジョブとして利用可能なPHP用のツールのインストール方法等（PHP版）を紹介した。

今回は前回紹介しきれなかったその他のツールについて紹介したいと思う。個々のツールのインストール方法等までは踏み込まず、その代わりなるべく多くのツールを紹介しよう。興味をもったツールを見つけたら、公式ページや紹介記事等を参照して欲しい。

XDEBUG

XDEBUG はさまざまなデバッグ機能を PHP に実装する拡張機能だ。独立したツールではないが、前回紹介した PHPUnit にカバレッジテストの機能を付与できる。PHPUnit の実行時に対象コードの何パーセントを実行できたかどうかを出力できるようになるので、テストが行われていないコードがあるかどうかを確認可能だ。XDEBUG を有効にして PHPUnit を実行すると、例えば以下のような出力が得られるようになる。

[root@6e9141b8b74e work]# phpunit  --coverage-text test/Sample_Class1Test.php
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.
Warning:        No whitelist configured for code coverage

...

Time: 205 ms, Memory: 7.50MB

OK (3 tests, 3 assertions)


Code Coverage Report:
  2018-08-03 02:11:39

 Summary:
  Classes: 100.00% (1/1)
  Methods: 100.00% (1/1)
  Lines:   100.00% (29/29)

@Sample::Sample_Class1
  Methods: 100.00% ( 1/ 1)   Lines: 100.00% ( 29/ 29)

“Code Coverage Report” と記載された部分があるが、ここにクラスごと、メソッドごと、そして行ごとにどのぐらいのコードが実行されたかが記載されている。この例ではいずれも100%になっているが、テストが不十分だと以下のようになる場合がある。

[root@6e9141b8b74e work]# phpunit  --coverage-text test/Sample_Class1Test.php
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.
Warning:        No whitelist configured for code coverage

.

Time: 189 ms, Memory: 7.50MB

OK (1 test, 1 assertion)


Code Coverage Report:
  2018-08-03 02:13:21

 Summary:
  Classes:  0.00% (0/1)
  Methods:  0.00% (0/1)
  Lines:   72.41% (21/29)

@Sample::Sample_Class1
  Methods:   0.00% ( 0/ 1)   Lines:  72.41% ( 21/ 29)

この例ではプログラムコードが全29行あるのに対し、そのうち21行しか実行されていない事が警告されている。このように必要なテストが十分に行われているかどうかを確認可能になるのが大きなメリットだ。

ただし、常にカバレッジ率100%のテストを記述する事は現実問題としてはなかなか困難が伴う。有限の時間の中でテストコードを記述する事を考えれば、ある程度で妥協しなければならない場合もあるだろう。品質と効率とをどのように図りに掛けていくかは大きな課題だが、各自で判断して頂きたい。

php7cc

php7cc公式サイト:https://github.com/sstalle/php7cc

コードがPHP7に対応しているかを確認するツールである。すでに PHP7への移行はかなり進んでいると思われるが、その一方、今でも PHP 5.x を利用している所も少なくないだろう。php7cc は PHP5用に記述されたプログラムコードを PHP7で動作させた時、どのような問題があるかを警告してくれるツールである。PHP7では利用できなくなる関数を利用している箇所や、配列変数に関連する細かな違い等について警告してくれるので、PHP5で動作させつつ、将来はPHP7で動作させたいコードを書く時に便利だ。

PHP_CodeSniffer, PHP-CS-Fixer

PHP_CodeSniffer 公式サイト:PHP_CodeSniffer: https://github.com/squizlabs/PHP_CodeSniffer
PHP-CS-Fixer 公式サイト:PHP-CS-Fixer: https://github.com/FriendsOfPHP/PHP-CS-Fixer

これらはコーディング規約のチェック、および修正を行うツールである。どちらも指定したコーディング規約に基づき、自動的に修正してくれるため運用しやすいツールになっている。
どちらもほぼ同じ機能を持っているが、PHP-CS-Fixer は PHP 5.6以降、および PHP 7.2 以降に対応なので注意が必要だ。対応しているデフォルトのコーディング規約は、 PHP-CS-Fixer が PSR1, PSR2, PSR4, Symfony等、 PHP_CodeSniffer が PSR1, PSR2, PEAR, Zend 等だ。もちろんルールのカスタマイズも可能だ。

なお、自動変換だけでは残留する問題も多い事に注意して欲しい。インデントや改行の方法等については適切な自動変換が行われるが、コメント不足や変数名までは修正してくれない。それらは手作業での修正が必要だ。

ところで独自のコーディング規約を採用している所も多いと思うが、独自コーディング規約をチェックしようと思ったら、ルールのカスタマイズでそれなりに苦労するかも知れない。大抵の場合、この手のツールは広く採用されているコーディング規約を前提として作られているからだ。もしこれからコーディング規約を定めるのなら、OSS 等で広く採用されている PSR2 をお勧めしたい。PSR2 は PHP のフレームワーク関係者達が共通で利用する事を目的に定めたコーディング規約だ。公式サイトは以下の通りである。

PSR2 公式サイト: https://www.php-fig.org/psr/psr-2/

Selenium

Selenium 公式サイト:https://www.seleniumhq.org/

UIテストの自動化ツールである。WEBアプリケーションの結合テストを自動化できるのが特徴だ。これらのテストではユニットテストでは見つけられないさまざまなバグを発見できるだろう。

Selenium は Version 2以降、web-driver というモジュールの概念を導入しており、スマホを含めたさまざまなブラウザでのテストが可能になっている。このためIE特有のバグ、iPhone版 Safari 特有のバグ等を検出できるのが大きなメリットだ。ただし、それらのテストを行うためには実機やエミュレーターが必要となる。
ユニットテストと同じくテストプログラムを記述する必要があり、ここに工数を割けるかどうかが導入時の最大の問題だと言える。ただし、ユニットテストを書くためには各クラスレベルでプログラムの動作を把握する必要があるが、UIテストは外部仕様さえ分かっていればテストを記述できる点が大きな違いだ。また PHP, Python, Ruby, .NET, Perl, Java等、さまざまな言語が利用でき、アプリケーションの本体がどのような言語で記述されているかに依存しない。これらの特徴から、業務で行うなら外注しやすい部分とも言えるだろう。

導入メリットは大きく、それ以外の方法ではおよそ発見できないようなバグも発見できる。筆者の周辺において、例えば以下のようなバグを Selenium の導入によって解決できた。

数年に渡る複数の開発会社の改修で肥大化した業務アプリケーションがあった。PHPで記述されているが開発会社間で共有可能な資料はER図程度であり、プログラムの詳細設計は各社に任されていた。Selenium による自動テストを実行した所、A社開発部分のあるページαを表示後に、B社開発部分のあるページβを表示すると不可解な現象が起こる事を確認できた。ページαとページβには何の接点も無いように思えた。詳細を調査した所、A社、B社が独自に定義したセッション変数がたまたま同じ名前になってしまっていたのが原因だった。この問題はページβで発生する原因不明の問題として報告されていたが、このテストを行うまでは再現方法が分からず、解決に至ってなかった。
他社から供給されている地図APIを利用し、Javacriptで描画された地図上のさまざまなポイントをクリックすると情報を表示するアプリケーションがあった。情報供給ポイントは数千ヵ所に及ぶが、Selenium で全ポイントをクリックした所、数ヵ所で期待しない動作が確認できた。詳細を調査した所、いくつかのポイントでのデータ入力ミスが原因だった。
A社のAPIをB社のライブラリを経由して利用するWEBアプリケーションをC社が開発していた。100分の1程度の確率でまれに期待しない動作が起こるのだが、再現条件が分からず解決策が見つからなかった。そこで Selenium で数千回の試行を行い、A社のAPIがエラーを返す時に、B社のライブラリが適切な処理を行っていない事を確認できた。

以上のように手作業ではなかなか確認が難しい問題を、膨大な反復作業によって追及できる。ブラウザ上で次々と機械的に画面内をクリックし、エビデンス(画面スクリーンショット)を自動的に蓄積していく様は見た目にも派手であり、顧客に与えるインパクトやプレゼン効果も高い。

Phing

Phing 公式サイト:https://www.phing.info/

各種ツールをバッチ処理化するツールであり、PHPMD, PHPCPD, PHPCS, phpdox等に対応している。CIに利用する make コマンド的なツールである。Phing を利用すれば、複数の処理をまとめて実行できる。

もっともバッチ化するだけなら10行程度のシェルスクリプトで十分な場合も多いだろう。にも関わらず Phing は極めて有効なツールだ。なぜなら Phingでは対応している各ツール用に Jenkins 用のプラグインを供給しているからだ。これによりPhingでバッチ化された処理は、Jenkins で視覚化できるようになる。