PHP Mentors

Eclipse PDTの機能と対応するコマンド・キーバインディングを表形式にまとめたチートシートをGitHubで公開しました。

• プロジェクト: https://github.com/phpmentors-jp/eclipse-pdt-cheat-sheet

本チートシートは編集操作、ウィンドウ操作、テスト（MakeGood）の3つのセクションで構成されており、特に編集操作については、コードを補完する、型を開く、宣言を開くといった、統合開発環境（IDE）ならではの機能で実際に私がよく使うものを中心にピックアップしてみました。

本チートシートの対象は主にEclipse PDTの初心者の方になると思いますが、コマンドを指が覚えるまでの練習用として使っていただければ幸いです。

チートシート（PDFファイル）をダウンロードする

2009年の秋にMakeGoodの開発を始めた頃、私の開発環境は大きく変わりました。GNU EmacsからEclipseへ、すなわちテキストエディターから統合開発環境（IDE: Integrated Development Environments）への変更です。IDEには数多くの利点がありますが、中でも型やメソッドの定義・参照へのアクセスの容易さは、さまざまなソフトウェアを読み解く上で大いに役立っています。

EclipseはOSGiという優れたモジュールシステムを採用しており、OSGiバンドル（OSGiのモジュール）であるEclipseプラグインだけでなくEclipseの実行環境もまたOSGiバンドルとして提供されています。ユーザーはそれらのプラグインを組み合わせて自分自身のEclipse環境を構築することができます。

プラグインは固有の更新サイト（Update Site）で公開されており、更新サイトをEclipseに追加することで、プラグインの検索・インストールを行うことができます。また、Eclipseに標準で組み込まれている、Marketplace Clientを使うと、Eclipse Marketplaceから直接プラグインの検索・インストールを行うことができます。

本記事ではEclipse Kepler (4.3)で作るPHPアプリケーション開発環境について解説します。

1. Eclipse Standard 4.3

まずは本体ですが、ダウンロードページから、お使いのプラットフォームに応じたアーカイブをダウンロードします。ダウンロードしたアーカイブを適当なディレクトリに展開しましょう。

2. PHP Development Tools（PDT）更新サイト

更新サイト:

http://download.eclipse.org/releases/kepler

PDTは、コード補完（Content Assist）やクラス・メソッド・関数宣言の参照等の機能を備えたエディター（PHP Editor）、フォルダー・ファイルからクラス・メソッドまでをツリー形式で表示するファイルブラウザー（PHP Explorer）、素早くファイルやクラスを開くOpen ResourceとOpen Type、PHPスクリプトの実行・デバッグ機能、その他多くの機能を提供する、PHPアプリケーション開発環境の基盤となるプラグインです。

PDTをインストールするには、まずEclipseを起動し、メニューバーから Help > Install New Software… を選択します。次にInstallダイアログのWork with:の部分でKepler - http://download.eclipse.org/releases/keplerを選択し、type filter textの入力欄にphpと入力します。次にPHP Development Tools (PDT)を一つ選択し、Next >ボタンをクリックします。

あとはウィザードを進めていき最後にFinishボタンをクリックします。

3. MakeGood Marketplace

MakeGoodはPDT上でユニットテストを実行するためのプラグインです。PHPUnitをはじめ各種テスティングフレームワーク向けのテストを同一のインターフェイス上で実行することができます。

MakeGoodはMarketplace Clientからインストールすることができます。最初にメニューバーから Help > Eclipse Marketplace… を選択します。次にEclipse MarketplaceダイアログのFind:の部分でmakegoodと入力し、Goボタンをクリックします。結果が表示されたら、MakeGoodのInstallボタンをクリックします。あとはウィザードを進めるだけです。

4. Eclipse Color Theme Marketplace

Eclipse Color ThemesではEclipseの各種エディターの配色をまとめたものがテーマとして配布されています。本プラグインによりビルトインテーマおよびインポートされたテーマによって配色を簡単に変更することができるようになります。

テーマは Window > Preferences > General > Appearance > Color Theme から選択、適用、インポートを行うことができます。私も3つのテーマを公開しています。よろしければ使ってみてください。私のおすすめはiteman Solarize lightです。

おわりに

以上、Eclipse Kepler (4.3)で作るPHPアプリケーション開発環境について見てきました。プラグインを組み合わせることで、Eclipseはより強力な開発環境となります。アプリケーション開発がより高度になっていく中でIDEの重要性は増す一方です。今までIDEを使ったことのない方も是非Eclipseを使ってみてください。

参考

• Eclipse.org - Kepler Simultaneous Release : Highlights
• New and Updated Solutions | Eclipse Plugins, Bundles and Products - Eclipse Marketplace
• PHPメンターズ -> Eclipseで快適にPHPアプリケーション開発を行うためのプラグイン5選

先週になりますが、MakeGoodのメジャーアップデートとなるバージョン2.0.0をリリースしました。具体的な変更点はリリースノートをご覧いただくとして、本記事では改めてMakeGoodについて簡単に解説したいと思います。

MakeGoodとは？

MakeGoodは継続的テスト（Continuous Testing）と呼ばれるプラクティスに基づいたユニットテスト実行環境であり、Eclipse PDT上で動作します。MakeGoodの中心にあるテーマは素早いフィードバックです。それは主にファイル保存時のテストの実行と失敗・エラー・致命的なエラーの自動的な追跡による、テスト実行ワークフローの自動化として表現されています。ここでいうテスト実行ワークフローとは以下のようなものです。

テスト実行ワークフロー

• テストの実行を準備する。
• テストを実行する。
• 結果の確認する。
• 失敗箇所を特定する。
• エディタを開く。

MakeGoodでは上記のワークフローが自動化されており、また極力目立たないように動作するため（画面右下の緑色の四角を見てください！）、開発者はエディタ上のプログラミングに集中することができます。

継続的テストとは？

継続的テストとは、開発者のマシン上でファイルが保存される度にバックグラウンドで自動的にテストを実行することによって、テストの失敗に関する迅速なフィードバックを提供しようとするものです。

最初に継続的テストを提唱したMITのProgram Analysis Groupの研究によると、継続的テストによって以下のような結果が得られたとされています。

• 継続的テストを用いる参加者は（用いない参加者よりも）3倍速く締め切り前にタスクを完了しそうな勢いであった。（An experimental evaluation of continuous testing during development）
• 継続的テストは（テストに関する）92-98%の無駄な時間を削減した。（Reducing wasted development time via continuous testing）

Object Mentorのブログ記事Continuous Testing Explainedでは、このような結果は以下の効果からきていると述べられています。

• テスト実行のオーバーヘッドを少なくする。
• 不具合発見までのラグを減少させる。
• TDDの良い習慣を促進する。
• テストの速さを維持する。

継続的インテグレーションとの違い

継続的インテグレーション（Continuous Integration）によるテストとの違いは、フィードバックの速さです。継続的テストではファイルを保存すると、数秒で結果が得られます。また、継続的テストが開発者個人のプログラミングの活動にフォーカスしていることも違いといえるでしょう。

ツールの重要性

継続的テストによる素早いフィードバックの恩恵を最大にするには自動的なテストの実行だけでは十分ではありません。テストが失敗した際にその原因を探る時間は馬鹿になりません。例えば、多くのコマンドラインツールでは、どのファイルの何行目のアサーションが失敗したのかを特定するには目視に頼る他はありません。また、特定したファイルをテキストエディタで開き、該当行に移動するのも手間がかかるでしょう。MakeGoodを使えばこのプロセスは瞬時に完了します。素早いフィードバックを標榜する開発者であれば、このオーバーヘッドを無視することはできないでしょう。

また、MakeGoodでは結果ツリーやスタックトレースからのクラス、メソッド、ファイルへのジャンプもサポートしていますので、Eclipse PDTの機能と合わせて素早く原因を探ることができます。これらはもちろんコマンドラインツールとテキストエディタで実現できないことではありませんが、同等の環境を構築するには相当の困難を伴うことは想像に難くありません。

MakeGoodに限らず、プログラミングにおいて適切なツールを使うことは、開発者がプログラミングそのものに注力するためにとても重要なことです。思慮深い開発者であれば、置かれた状況にとって適切なツールを好みや固執を乗り越えて選択することができるでしょう。

おわりに

MakeGoodは今後とも素早いフィードバックを原則として開発を進めていきます。まだ使ったことがない方も是非一度お試しください。きっと気に入っていただけると確信しています。

参考

• Eclipse PDT のための継続的テストランナー v2 - MakeGood - Piece Framework
• Continuous Testing - PAG
• Continuous Testing Explained

MakeGoodでテスティングフレームワークを使う場合の選択肢として、プロジェクトの外部に配置されているパッケージを使う方法と、内部に配置されているパッケージを使う方法があります。今日ではComposerを使うことで、開発時のみに必要とされるパッケージでも簡単にプロジェクトの内部に配置することができるようになりました。

必要なパッケージの多くをプロジェクトの内部に配置することは、アプリケーションの動作を保証する上で有用なプラクティスといえるでしょう。しかし、Eclipse PDTからの利用を考慮すると、多くのプロジェクトで使われることが予想されるテスティングフレームワークやモッキングフレームワーク等について、単一の環境のものを使うことによるパフォーマンス上のメリットは小さくはありません。また、通常のフレームワークやライブラリと比較すると、テストコードの動作に与える影響は極めて小さいため、外部のものを使うデメリットもほとんどないといっていいでしょう。

今回の記事では、PEARパッケージ管理システムPyrusを使用してプロジェクトの外部にユーザー固有のPEAR環境を構築し、それらをMakeGoodから利用する手順について解説します。

Pyrusによるユーザー固有のPEAR環境の構築

まず今回作成するPEAR環境のディレクトリ構造を以下に示します。インストールするPEARパッケージはPHPunitとPhakeとします。

PEAR環境のディレクトリ構造

├── bin
│ └── pyrus.phar
└── vendor
    ├── phake
    │ └── php
    │     ├── Phake
    └── phpunit
        └── php
            ├── PHPUnit

vendorディレクトリにはPHPUnitとPhake、それぞれ個別のPEARパッケージを配置します。binディレクトリには本環境で使用するPyrusのPharアーカイブを配置します。

PEAR環境のパス

PEAR環境のパスはどこでも構いませんが、ユーザーが書き込み権限を持つディレクトリを用意しましょう。本記事で使用するパスは~/site-phpとします。

Pyrusのインストール

PyrusのPharアーカイブpyrus.pharをPEAR2のWebサイトからダウンロードし、~/site-php/binディレクトリに配置します。

Pyrusの設定

PEARパッケージのインストールの前にPyrusを設定します。まず以下のようにPyrusを初期化します。

$ php ~/site-php/bin/pyrus.phar
Pyrus version 2.0.0a4 SHA-1: 72271D92C3AA1FA96DF9606CD538868544609A52
Pyrus: No user configuration file detected
It appears you have not used Pyrus before, welcome!  Initialize install?
Please choose:
  yes
  no
[yes] :
Great.  We will store your configuration in:
  /home/iteman/.pear/pearconfig.xml
Where would you like to install packages by default?
[/home/iteman] : /home/iteman/site-php
You have chosen:
/home/iteman/site-php
Thank you, enjoy using Pyrus
Documentation is at http://pear.php.net
Using PEAR installation found at /home/iteman/site-php
...

続いていくつかのパラメーターの値を設定します。

$ php ~/site-php/bin/pyrus.phar set auto_discover 1
$ php ~/site-php/bin/pyrus.phar set cache_dir ~/site-php/tmp/pyrus/cache
$ php ~/site-php/bin/pyrus.phar set temp_dir ~/site-php/tmp/pyrus/temp
$ php ~/site-php/bin/pyrus.phar set download_dir ~/site-php/tmp/pyrus/downloads

PEARパッケージのインストール

次にPHPUnitとPhakeのPEARパッケージをインストールします。基本となるコマンドはmypearとinstallです。mypearコマンドで対象パッケージの配置先ディレクトリを決定し、installコマンドでインストールを実行します。

PHPUnitのインストール

最初にPHPUnitをインストールします。基本と異なるのはパラメーターbin_dirを設定している箇所です。ここではbin_dirにPHPUnitの配置先ディレクトリを設定しています。

$ php ~/site-php/bin/pyrus.phar mypear ~/site-php/vendor/phpunit
$ php ~/site-php/bin/pyrus.phar set bin_dir ~/site-php/vendor/phpunit/bin
$ php ~/site-php/bin/pyrus.phar install pear.phpunit.de/phpunit
Pyrus version 2.0.0a4 SHA-1: 72271D92C3AA1FA96DF9606CD538868544609A52
Using PEAR installation found at /home/iteman/site-php/vendor/phpunit
Sorry, the channel "pear.phpunit.de" is unknown.
Discovery of channel pear.phpunit.de successful
Sorry, pear.phpunit.de/phpunit references an unknown channel pear.symfony-project.com for pear.symfony-project.com/YAML
Discovery of channel pear.symfony-project.com successful
Downloading pear.phpunit.de/PHPUnit
...
Installed pear.phpunit.de/PHPUnit-3.6.12
Installed pear.phpunit.de/File_Iterator-1.3.1
Installed pear.phpunit.de/Text_Template-1.1.1
Installed pear.phpunit.de/PHP_CodeCoverage-1.1.3
Installed pear.phpunit.de/PHP_Timer-1.0.2
Installed pear.phpunit.de/PHPUnit_MockObject-1.1.1
Installed pear.symfony-project.com/YAML-1.0.6
Installed pear.phpunit.de/PHP_TokenStream-1.1.3
Optional dependencies that will not be installed, use --optionaldeps:
pear.phpunit.de/PHP_Invoker depended on by pear.phpunit.de/PHPUnit

Phakeのインストール

次にPhakeをインストールします。

$ php ~/site-php/bin/pyrus.phar mypear ~/site-php/vendor/phake
$ php ~/site-php/bin/pyrus.phar install pear.digitalsandwich.com/phake
Pyrus version 2.0.0a4 SHA-1: 72271D92C3AA1FA96DF9606CD538868544609A52
Using PEAR installation found at /home/iteman/site-php/vendor/phake
Sorry, the channel "pear.digitalsandwich.com" is unknown.
Discovery of channel pear.digitalsandwich.com successful
Downloading pear.digitalsandwich.com/Phake
...
Installed pear.digitalsandwich.com/Phake-1.0.2

これでユーザー固有のPEAR環境の構築は完了です。

MakeGoodからの利用

さて、この段階ではMakeGoodからPEAR環境を利用することができないため、MakeGoodビューには以下のようにPHPUnit_Framework_TestCaseクラスが利用できません。修正…というメッセージが表示されます。

プロジェクトからPEAR環境を利用するには、ユーザーライブラリの定義とプロジェクトへのユーザーライブラリの追加という2つの作業が必要になります。

ユーザーライブラリの定義

ユーザーライブラリは、ユーザー環境のライブラリをプロジェクトから任意の名前によって参照するための仕組みです。ユーザー固有のライブラリパスをプロジェクトから隠蔽することができるため、PHPプロジェクトを複数人で共有する場合に重宝する機能です。

ここではさきほど準備したPHPUnitをユーザーライブラリとして定義します。まず、メニューバーからWindow -> Preferences…を選択し、続いてPHP -> PHP Librariesを選択します。次にNew…ボタンをクリックし、ライブラリの名前を入力後OKボタンをクリックします。

次に先程定義したユーザーライブラリを選択しAdd External folder…ボタンをクリックします。次にフォルダー選択ダイアログからPHPUnitが配置されているフォルダー/home/iteman/site-php/vendor/phpunit/phpを選択します。

同様の手順でPhakeをユーザーライブラリとして定義します。

プロジェクトへのユーザーライブラリの追加

プロジェクトからユーザーライブラリを参照するためには、プロジェクトにユーザーライブラリを追加する必要があります。まず、プロジェクトのプロパティを開きPHP Include PathのLibrariesタブを選択し、続いてAdd Library…ボタンをクリックします。次にUser Libraryを選択しNext >ボタンをクリックします。

次に先程定義したユーザーライブラリにチェックを入れてからFinishボタンをクリックします。

問題なければテストの実行を待っています…というメッセージがMakeGoodビューに表示されます。

参考

• PEAR2_Pyrus - PEAR2
• 概要 - MakeGood - Piece Framework

Eclipseにはビューおよびエディターのレイアウトとメニュー構成をひとまとめにしたパースペクティブと呼ばれる概念があります。様々なプラグインが用途に応じたパースペクティブを提供しており、PDTもPHPパースペクティブを提供しています。

これらのパースペクティブは自分が使いやすいようにカスタマイズすることができます。早速、PHPパースペクティブを基にレイアウトや表示するビューを変更してみましょう。

レイアウトの変更

レイアウトを変更するには、ビューやエディターが配置されている土台部分をドラッグアンドドロップで移動します。この時ビューやファイル名が表示されている部分ではなく、それらの右側の何も表示されていない部分を掴むようにすると、複数のビューが表示されている場合も全体を移動することができます。

ビューの追加と削除

おおよそのレイアウトが定まったら、ビューの追加と削除を行います。ビューを追加するには、メニューバーから Window -> Show View -> Other… を選択し、対象のビューを選択します。ビューを削除するにははビューのタブの右側にある x ボタンをクリックします。

ビューの追加と削除が完了したら、パースペクティブのそれぞれの部分において、パースペクティブを開いたときにデフォルトで表示したいビューを表に見えるようにしておきます。

パースペクティブの保存

パースペクティブが納得いくものになったら名前を付けて保存しておきましょう。パースペクティブを保存するにはメニューバーから Window -> Save Perspective As… を選択し、名前を入力後 OK ボタンをクリックします。

パースペクティブが保存できたら一度確認してみましょう。メニューバーから Window -> Close Perspective を選択し、一旦パースペクティブを閉じます。次にメニューバーから Window -> Open Perspective -> Other… を選択し、さきほど保存したパースペクティブを選択します。問題なく表示されましたか？

なお、パースペクティブはワークスペースの設定として保存されているためエクスポート・インポートすることができます。

ノート Eclipse Juno (4.2)ではパースペクティブのエクスポート・インポートはできません。Bug 378811 – Support separation of the Workspace and the saved UI Model (was: can’t save and import perspectives)

MakeGoodビューを使いやすくするために

最後にMakeGoodビューを使いやすくするための指針を紹介したいと思います。

• 縦 - テスト結果の領域に3つ以上の要素が表示されるようにする。
• 横 - プログレスバー、タイマー、カウンターの数字が省略されないようにする。

おわりに

本記事の画像は私が使っているパースペクティブのものですが、これはノートパソコンの1366x768という解像度に合わせて調整したものです。エディター領域は最大限確保しつつ、PHP ExplorerやOutlineはそれぞれ実用レベルの大きさにし、MakeGoodビューのテスト結果領域には5つの要素が表示できるようにしました。

デフォルトのパースペクティブに満足することなく、ディスプレイの数や大きさ、解像度などお使いの環境に適したパースペクティブを是非ご自身の手で作ってみてください。

Symfony Advent Calendar JP 2012 - Day 7

Symfonyでアプリケーションを開発する際に利用できる、Eclipse PDTとSymfony Plug-inを導入した環境での入力補完（特にSymfony統合の部分）について紹介します。

使用したEclipse、PDT、Symfony Plug-in等のバージョンは以下になります。p2-nightlyリポジトリから開発最新版をインストールしています。現時点では安定版ではありませんのでご注意ください。

• Eclipse Version: 4.3.0 Build id: I20121031-2000
• PDT Core Plug-in Version 3.1.1.201209101312
• PDT Extensions Core Plug-in Version 0.0.13.201212042111
• Symfony Core Plug-in Version 1.0.88.201212041906
• Symfony Twig Plug-in Version 1.0.88.201212041906

PDT Extensions group

が提供するupdate-siteの

p2-nightly

には、上記を含めたPHP向けの最新のプラグイン一式が登録されています。

Symfony Plug-inを導入したEclipseでプロジェクトのSymfony natureを有効にすると、様々な入力補完が利用できます。

テンプレートリソースの論理名補完

Symfonyではテンプレートを「バンドルクラス名:リソースディレクトリ名:ファイル名」のようにコロンで区切った3つのパートから成る論理名で指定します（例：AcmeDemoBundle:Demo:hello.html.twig）。

コントローラクラスのrender()メソッドの第1引数のように、テンプレート論理名を要求する箇所にて文字列の引用符内で補完を起動すると、テンプレート論理名が補完されます。論理名の最初のパートはバンドルクラス名なので、バンドルクラス名の一覧が表示され、インクリメンタルに絞り込むなどして補完入力が可能です。候補一覧では名前の左にバンドルであることを示す「B」アイコンが表示されます。

バンドルクラス名を決定し2つ目のパートに入ると、選択したバンドル内のリソースディレクトリの一覧が表示されます。（※現時点ではコントローラクラス名と対応しているものしかリストアップされないようです。）候補一覧では、名前の左にコントローラであることを示す「C」アイコンが表示されます。

3つ目のパートでは、選択したバンドルのリソースディレクトリにあるテンプレートファイルの一覧が表示されます。候補一覧では、名前の左にテンプレートファイルであることを示す「T」アイコンが表示されます。

このようにリソースの名前が長くなっても、補完を使ってポンポンと素早く正確に入力できます。

ルート名の補完

テンプレート名の補完と同様に、ルート名も補完で入力できます。コントローラクラスのgenerateUrl()メソッドの第1引数のように、ルート名を要求する箇所にて文字列の引用符内で補完を起動すると、ルート名が補完されます。候補一覧では、名前の左にルート名であることを示す「R」アイコンが表示されます。

この補完候補一覧ウィンドウから候補を選ぶ（決定ではなく）と、そのルートの情報がホバーウィンドウに表示されます。ルートのURLパターンやパラメータのリスト、バインドされるアクションメソッド等をその場で確認できます。

サービス名の補完

DIコンテナに登録されているサービス名も補完で入力できます。コントローラクラスのget()メソッドの第1引数のように、サービス名を要求する箇所にて文字列の引用符内で補完を起動すると、サービス名が補完されます。候補一覧では、名前の左にサービスであることを示す「S」アイコンが表示されます。

Twigテンプレート上での補完

Symfony Plug-inとTwig Plug-inを合わせて導入しておくと、Twigテンプレート上でもSymfonyインテグレーションが有効になります。例えばTwigテンプレートでextendsにより継承元テンプレートリソースを指定する場合、コントローラでのrender()メソッドと同様に論理名を補完入力できます。

さらにextends先テンプレートでは、blockの補完も行えます。継承元で定義されているblock名を補完入力できます。

まとめ

暗黙の規約がほとんどゼロであるSymfonyでは、リソースの指定などにおいて明示性が重視されているため、すべて手入力していると手間になります。同時に誤入力の可能性も高まります。IDEの機能をフル活用すれば、入力の手間と誤入力の防止を同時に実現できます。Symfonyとの高次なインテグレーションを実現するEclipse + PDT + Symfony Plug-inは、SymfonyでWebアプリケーションを開発する上で必須ともいえるツールになっていくでしょう。

2年ほどMacVimで開発していた私ですが、Eclipseでの開発に切り替えました。この話はまた別のエントリで紹介させていただきます。

Eclipse PDTのPHPプロジェクトとしてSymfony Standard EditionベースのSymfonyアプリケーションを追加すると、DLTKのバリデーションによって大量のエラーが見つかります。

これらはすべてSensioGeneratorBundleのテンプレートファイルが原因ですが、このように明らかに不要なバリデーションエラーは抑止したいところです。

DLTKのバリデーションはプロジェクトのPHP Build Pathに含まれるファイルに対して行われるため、バリデーションの対象から外したいファイルをPHP Build Pathに含めないようにすることでこの問題を解決できます。

まずPHP Build Pathにプロジェクトルート以下のディレクトリが個別に登録されている場合、それらを削除します。(Removeボタン)

次にPHP Build Pathにプロジェクトのルートディレクトリを追加します。(Add Folder…ボタン)

これで一旦プロジェクトのすべてのファイルがバリデーション対象となりました。

次に先程追加したルートディレクトリのExcludedを編集します。(Edit…ボタン) Exclusion patternsにSensioGeneratorBundleのテンプレートファイルのディレクトリ(vendor/bundles/Sensio/Bundle/GeneratorBundle/Resources/skeleton/)を追加します。(Add…ボタン)

以上で当該プロジェクトの不要なバリデーションエラーを抑止することができました。

Piece Projectは先日11月1日にStagehand_TestRunner 3.6.2、11月3日にMakeGood 2.5.0をリリースしました。

MakeGood 2.5.0

テスト結果レイアウトとしてタブまたは水平のいずれかを選択できるようになりました。

Eclipse起動時のデフォルトはタブになっています。これはワークスペースの設定で変更することができます。

詳細およびその他の変更についてはリリースノートをご覧ください。

Stagehand_TestRunner 3.6.2

継続的テスト実行時の不具合を修正しました。

Stagehand_TestRunner v4の構想

現在Stagehand_TestRunnerのメジャーバージョンアップを計画中です。新たにいくつかのテスティングフレームワークのサポートを追加し、現行のPHPUnit以外のサポートを廃止するつもりです。

Stagehand_TestRunner v4についてご意見ご要望がありましたら本記事へのコメントやGitHubのIssuesで是非お聞かせください。また、Pull Requestもお待ちしております。

本ブログではこれまで「Stagehand_TestRunnerおよびMakeGoodによるSymfonyの機能テストの実行」、「Symfonyアプリケーションのテスト実行環境を改善する」といった記事でSymfonyのユニットテスト実行環境の構築についてご紹介してきました。本記事ではSymfony2ベースのユーザー登録サンプルで私たちが採用している、PHPUnit、Stagehand_TestRunner、MakeGoodいずれにも対応したユニットテスト実行環境の構築手順を改めてご紹介します。

ユニットテスト実行用ブートストラップファイルの作成

最初にユニットテスト実行用のブートストラップファイルとして以下のようなPHPスクリプトを作成します。

app/bootstrap_test.php:

<?php
$_SERVER['KERNEL_DIR'] = __DIR__;
require_once $_SERVER['KERNEL_DIR'] . '/bootstrap.php.cache';

PHPUnit以外のプロダクトでComposerのオートローディングが有効でないものを使う場合、このファイルでロードや設定を行うようにします。例えば、インクルードパス上にあるPhakeを使う場合のコードは以下のようになります。

app/bootstrap_test.php:

<?php
$_SERVER['KERNEL_DIR'] = __DIR__;
require_once $_SERVER['KERNEL_DIR'] . '/bootstrap.php.cache';

require_once 'Phake.php';
Phake::setClient(Phake::CLIENT_PHPUNIT);

Note ブートストラップファイルはStagehand_TestRunnerまたはMakeGoodのプリロードスクリプト機能とPHPUnitのブートストラップ機能によって2回ロードされることがあります。したがって、ブートストラップファイルのコードは、複数回ロードされても問題が発生しないようにしておかなければなりません。

ユニットテスト実行環境の設定

次に前述のブートストラップファイルを使用するようにPHPUnitのXML設定ファイルを変更します。

app/phpunit.xml.dist:

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

<!-- http://www.phpunit.de/manual/current/en/appendixes.configuration.html -->
<phpunit
    ...
    bootstrap                   = "bootstrap_test.php">
...

テストランナーとしてMakeGoodを使用する場合はプロジェクトのプロパティを以下のように設定します。

1. プロジェクトのプロパティを開き、MakeGoodを選択します。
2. テスティングフレームワークでPHPUnitを選択します。
3. テストフォルダーにsrcディレクトリを追加します。
4. プリロードスクリプトに前述のブートストラップファイルのパスを入力します。

ユニットテストの実行

最後にそれぞれのテストランナーのユニットテスト実行方法を示します。

PHPUnit

$ php /path/to/phpunit -c app/phpunit.xml.dist

Stagehand_TestRunner

$ php /path/to/testrunner phpunit -p app/bootstrap_test.php -R src

Stagehand_TestRunner（phpunit:passthroughコマンド）

$ php /path/to/testrunner phpunit:passthrough -p app/bootstrap_test.php -c app/phpunit.xml.dist

Note phpunit:passthroughはStagehand_TestRunner経由でphpunitコマンドを実行するコマンドです。Stagehand_TestRunnerでは1つのファイルに複数のテストクラスを定義することができますが、phpunitでは1つのファイルに1つのテストクラスしか定義することができません。したがって、1つのファイルに複数のテストクラスが定義されている場合、phpunitコマンドではすべてのテストを実行できず、カバレッジ等が使い物にならないという状況が発生します。phpunit:passthroughコマンドを使うと、1つのファイルに複数のテストクラスが定義されている場合でもすべてのテストを実行することができます。

MakeGood

継続的テストが有効な場合はファイルを保存する度に自動的にテストが実行されます。また、MakeGoodビューやコンテキストメニューからいつでも任意のテストを実行することもできます。詳細についてはMakeGoodユーザーガイドをご覧ください。

参考

• Symfony2ベースのユーザー登録サンプル

2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。

セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。

今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。

レポートは @smori1983 が担当させていただきます。

当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントにて公開されています。Coplien さんのおもしろTシャツにも注目しながら、ぜひご覧ください。

• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 1 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 2 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 3 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 4 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (extra)

全体の流れ

全体の流れとしては、1980年代以降のソフトウェア開発の歴史を、主にオブジェクト指向に対する考え方の変遷を通して振り返りつつ、MPD と DCI の関係性に迫るものとなりました。

オブジェクト指向（1988）

当時は C++ の他に、テレコム業界向け言語である CHILL や、軍需産業向け言語である Ada などの言語があり、それらの言語がオブジェクト指向なのかという議論がされていました。

最終的に C++ が残ることになりますが、C++ の作者である Stroustrup 氏は、そもそも C++ をオブジェクト指向言語ではなく、マルチパラダイム言語と定義していたことに注意する必要があります。

当時考えられていたオブジェクト指向の構成要素は次の3項目でした。

1. inheritance / 継承
2. polymorphism / ポリモーフィズム
3. instantiation / インスタンス化

1994年に Coplien さんは David Weiss 氏と Robert Chi Tao Lai 氏とともに仕事をしますが、その時、共通性／可変性分析を通じて、ソフトウェアファミリの振る舞いなどを特徴づけ、当時取り組んでいたソフトウェアのための DSL(Domain Specific Language) を開発しました。開発言語は C でした。

この、共通性に注目してグルーピングしたものをファミリと定義する方法は、Weiss 氏らが考案したFAST(Family Abstraction Specification Technique) という手法に基づいています。

DSL は小さなドメインを対象にしていて、ドメインが変化しない限りはうまくいったそうですが、ドメインは変化していくものです。DSL は、デバッガなど周辺技術との密な関係性の中で成立するため、その変化に対しては脆いという問題がありました。

ただし、共通性／可変性分析自体は非常に有用で、ドメイン分析に対しては非常に多くの収穫があったそうです。

分析の結果得られる共通性／可変性テーブルの内容の埋め込み（注: 解決ドメインの抽象による実装）に関して、

• DSL で埋め込むと、固くなりすぎ、脆くなる。
• C で埋め込むと、言語特有の制約が多く、開発者の intentionality（意図）がわからなくなる。

という課題がありましたが、C++ を用いることで、よりうまくいくようになりました。

オブジェクト指向（1995）

Coplien さんは、C++ を

共通性／可変性分析のための、汎用言語キットである

と捉えます。

その視点で見たオブジェクト指向は、次の4項目の構成要素で理解されるようになりました。

1. Common Signature
2. Common Data
3. Variation in Data
4. Variation in Algorithm

また、polymorphism / instantiation は、共通性／可変性のバインディングタイム（注: 共通性／可変性が変数に束縛されるタイミング）の選択の問題として捉え直されることになりました。

オブジェクト指向（DCI 時代）

Coplien さんによれば、更にこの後、3段階の気付きを経て、現在のオブジェクト指向理解へとつながっているそうです。

1段階目: There  is no OO in C++

• 2010年くらいまでは、オブジェクト指向という言葉を、抽象データ型（ Abstract Data Type: ADT ）という意味で使っていた。
• C++ は実際には抽象データ型ではなく、具象データ型（ Concrete Data Type: CDT ）であるということ。

2段階目: There are no objects in source code

• C++ プログラムはソースコードである。
• そこにはオブジェクトは存在しない。ソースコードに記述しているのはクラスである。
• 多くの人々が Java などの言語でやっているのはクラス指向プログラミングである。

3段階目: OO is mental model

• Trygve Reenskaug 氏とオブジェクトとは何か、オブジェクトパラダイムとは何かについて話し合い、DCI が生まれた。
• DCI は、抽象データ型の実装を意味したこれまでのオブジェクト指向とは別の視点を与える。
• 実行時におけるオブジェクトのネットワークがどのように問題を解決するかに注目する（ Alan Kay の定義）。
• 我々はクラスとロールをごちゃまぜにして考えていた。
  • 抽象データ型について考えるのがクラス指向。
  • ロールについて考えるのがオブジェクト指向。
  • 抽象データ型＋インスタンス化がロールを実行（play）。

MPD と DCI

MPD は、クラス指向のレイヤーにおいてドメイン分析を行う時、ソフトウェアファミリの共通性／可変性分析を通じてドメインモデルを構築する手法を提供します。

DCI は、我々のメンタルモデルに基づいて、オブジェクトどうしの相互作用を定義します。そこでは、抽象データ型としてのクラスに具体的なロールを注入されたオブジェクトが、特定のコンテキストのもとに配置され、相互作用するという、動的な側面を捉える方法を提供します。

以上を簡単にまとめると、次の表のようになるかと思います。

歴史的には MPD が先行しました。それは後に、モデルの静的な構造の分析を行うための領域を担う設計方法論という捉え直しがされました。そして、オブジェクト指向に対する新しい視点を提供する DCI が、クラス指向では扱うことが難しかった、モデルの動的な関係性を捉えるための方法論として提起されています。

Time and Space と DCI における共通性／可変性

DCI は、オブジェクトどうしの相互作用に注目します。つまり基本的には時間の経過（シーケンス）が意識されます。しかし、あるロールを付与された複数のオブジェクトが配置されてこそ、相互作用が成立するものです。

コンテキストとは、このように、ある状況に参加する主体の空間的配置と時間的な相互作用の総体として捉えられるものと言えます。

ここで、日本人にとってはありふれた「間」という概念が取り上げられました。具体例としては次のようなものが話題にあがりました。

• 歌舞伎（ Coplien さん）
• 龍安寺の石庭（ @koriym さん）

また、アレグザンダーの考案したパターンランゲージに話が及びました。パターンランゲージは、建築の構造（空間的なパターン）だけではなく、その構造が生み出す人々の相互作用（時間的なパターン）も内包したものとして理解されるべきです。

pattern of behavior = pattern in space + pattern in time

セッションの終盤では、このように、DCI が担う領域における共通性／可変性概念の適用可能性が示唆されました。

さいごに

会場を提供していただきましたヴァル研究所様、DCI Tokyo スタッフの皆様、今回もすばらしいイベントとなりました。ありがとうございました。

次回は、ワークショップ形式での開催も視野に入れながら、DCI Tokyo 3 が開催されることと思います。MPD / DCI / Lean Architecture に興味のある方は、ぜひご参加ください。