5月12日（土）に大阪の大阪産業創造館イベントホールにて開催された、PHPカンファレンス関西2012にて、LTでの発表を行いました。
LTでは、「モックオブジェクトの使い所」と題しまして、隣接オブジェクトのある簡単な構造を例に、悪い例と良い例およびモッキングフレームワークにPhakeを使ったコード例などを紹介しました。
資料末で紹介している、SymfonyのテストコードにてPHPUnitのモックオブジェクトを使っている箇所をPhakeで書き換える例については、以下の記事をご参照ください。
ユニットテストにおけるモックオブジェクトの使い方等、今後も勉強会やトレーニングサービス、メンタリングサービス等を提供してまいります。ご質問、お問い合わせ等お気軽にご連絡ください。
See more posts like this on Tumblr
#mocking #testingSymfony Advent Calendar JP 2011の3日目の記事です。
みなさん、Symfony2本体のソースコードやテストコードを読んだことはありますか？ Symfony2本体は、コアコンポーネント、コアバンドル等で成り立っており、それぞれ独立したテストコードが付属しています。PHPUnitのモックオブジェクト等を使ったテストがふんだんにあり、レイヤー化されたコンポーネントのテスト方法の参考になります。
今回は、Symfony Componentの中核をなす「HttpKernel」コンポーネントの中の、Kernelクラスのテストを1つ見てみましょう。
tests/Symfony/Tests/Component/HttpKernel/KernelTest.php:
<?php
// snip
namespace Symfony\Tests\Component\HttpKernel;
use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\HttpKernel\Bundle\BundleInterface;
use Symfony\Component\HttpKernel\Bundle\Bundle;
use Symfony\Component\HttpKernel\HttpKernelInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Config\Loader\LoaderInterface;
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel = $this->getMockBuilder('Symfony\Tests\Component\HttpKernel\KernelForTest')
->disableOriginalConstructor()
->setMethods(array('initializeBundles', 'initializeContainer', 'getBundles'))
->getMock();
$kernel->expects($this->once())
->method('initializeBundles');
$kernel->expects($this->once())
->method('initializeContainer');
$kernel->expects($this->once())
->method('getBundles')
->will($this->returnValue(array()));
$kernel->boot();
}
このコードではKernelクラスのboot()メソッドをテストしていますが、その中でもboot()メソッドの基本的な振舞をテストしている部分です。上記コードからは、boot()メソッドの基本的な振舞は次の内容だということになります。
このような振舞をテストするために、PHPUnitのモックオブジェクトの機能が使われています。 モックオブジェクトを使うことで、期待するメソッドが呼び出されたどうかをテストすることができるようになります。
この例では、テスト対象となるメソッドのクラス（Kernelクラス）自身をモックオブジェクトにしていますが、一般的にモックオブジェクトが必要となるのは、テスト対象のクラス/メソッドで依存している別のクラスがある場合です。それらをモックオブジェクトで置き換え、依存メソッドの呼び出しをエミュレートするとともに、意図したとおりに呼び出されたことも検査できます。
このように、テストにおいて単に対象メソッドの入出力だけを検査するのではなく、モックオブジェクトを使ってメソッドの振舞の部分もテストで表現できるようになるのです。モックオブジェクトを使ったテストコードを読みこなせるようになれば、Symfonyのテストコードをサクサクと理解できるようになり、それぞれのコンポーネントがどういった意図を持って作られているのかといったことについても理解が進むようになります。
PHPユーザーであれば、PHPが標準で持つ多くの内部（ビルトイン）関数や定数には日常的にお世話になっていることでしょう。これらの内部関数・定数はPHPの便利さの象徴といえます。しかし、内部関数や定数の使用はテストのしやすさを低下させる原因となります。以下のコードを見てみましょう。
<?php
...
class CollectingType
{
protected $type;
protected $expectedSuperTypes = array();
...
public function isTest()
{
if (in_array($this->type, $this->expectedSuperTypes)) {
return false;
} else {
foreach ($this->expectedSuperTypes as $expectedSuperType) {
if (is_subclass_of($this->type, $expectedSuperType)) {
return true;
}
}
return false;
}
}
...
isTest()は与えられた型（$typeフィールドの値）が使用中のテスティングフレームワークのテストにあたるかどうかを判定するメソッドです。判定には内部関数であるis_subclass_of()を使用しています。isTest()メソッドをテストする場合、is_subclass_of()関数の結果を変更するために本物の型を引数として使用する必要があります。これには実際に複数のクラスが必要となるため準備に手間がかかります。また、ここでテストしたいのはisTest()メソッドのロジックであってis_subclass_of()関数が正しく動作することではありません。
では、どうすればいいのでしょうか？1つの方法はis_subclass_of()関数の呼び出し部分をメソッドとして抽出し、そのメソッドの呼び出しをモックに置き換えることです。この場合プロダクションコードは以下のようになります。
<?php
...
class CollectingType
{
...
public function isTest()
{
if (in_array($this->type, $this->expectedSuperTypes)) {
return false;
} else {
foreach ($this->expectedSuperTypes as $expectedSuperType) {
if ($this->isSubTypeOfExpectedSuperType($this->type, $expectedSuperType)) {
return true;
}
}
return false;
}
}
...
protected function isSubTypeOfExpectedSuperType($type, $expectedSuperType)
{
return is_subclass_of($type, $expectedSuperType);
}
...
モッキングフレームワークPhakeを使った場合のテストコードは以下のようになります。
<?php
...
class CollectingTypeTest extends \PHPUnit_Framework_TestCase
{
public function typeToResultMap()
{
return array(
array('PHPSpec\Context', true, false),
array('DescribePHPSpecPass', true, true),
array('Foo', false, false),
);
}
/**
* @test
* @dataProvider typeToResultMap
*/
public function 型がテストかどうかをチェックする($type, $isSubTypeOfExpectedType, $isTest)
{
$collectingType = \Phake::partialMock(
'\Stagehand\TestRunner\Collector\CollectingType',
$type,
array('PHPSpec\Specification\ExampleGroup', 'PHPSpec\Context')
);
\Phake::when($collectingType)
->isSubTypeOfExpectedSuperType($this->anything(), $this->anything())
->thenReturn($isSubTypeOfExpectedType);
$this->assertThat($collectingType->isTest(), $this->equalTo($isTest));
}
...
このように関数の呼び出しをメソッドの呼び出しに置き換えることで、部分的にモックが適用されたオブジェクト（パーシャルモック）を使ったテストが可能になります。
この方法の問題点はテストの都合によってプロダクションコードの変更が必要になることです。例え同じ関数であったとしても、クラスが異なれば再度同じことを行う必要があります。加えてパーシャルモックはDIコンテナとの統合が難しいため、テストコードにオブジェクトの構成の知識が流出することになります。
もう1つの方法は関数のラッパーオブジェクト（私はレガシープロキシーと呼んでいます。）を導入することです。最初に以下のようなクラスを用意します。メソッド名、引数は置換対象の関数と同じにしておきます。
<?php
...
class LegacyProxy
{
...
public function is_subclass_of($object, $class_name)
{
return is_subclass_of($object, $class_name);
}
...
次にLegacyProxyオブジェクトを使ってプロダクションコードを書き換えます。
<?php
...
class CollectingType
{
...
protected $legacyProxy;
...
public function setLegacyProxy(LegacyProxy $legacyProxy)
{
$this->legacyProxy = $legacyProxy;
}
...
public function isTest()
{
if (in_array($this->type, $this->requiredSuperTypes)) {
return false;
} else {
foreach ($this->requiredSuperTypes as $expectedSuperType) {
if ($this->legacyProxy->is_subclass_of($this->type, $expectedSuperType)) {
return true;
}
}
return false;
}
}
...
最後にテストコードを書き換えます。先ほどのパーシャルモックの代わりにLegacyProxyオブジェクトをモックオブジェクトで置き換えます。
<?php
...
Class CollectingTypeTest extends \PHPUnit_Framework_TestCase
{
/**
* @test
* @dataProvider typeToResultMap
*/
public function 型がテストかどうかをチェックする($type, $isSubTypeOfExpectedType, $isTest)
{
$legacyProxy = \Phake::mock('Stagehand\TestRunner\Util\LegacyProxy');
\Phake::when($legacyProxy)
->is_subclass_of($this->anything(), $this->anything())
->thenReturn($isSubTypeOfRequiredSuperType);
$collectingType = new CollectingType(
$type,
array('PHPSpec\Specification\ExampleGroup', 'PHPSpec\Context')
);
$collectingType->setLegacyProxy($legacyProxy);
$this->assertThat($collectingType->isTest(), $this->equalTo($isTest));
}
...
この方法では、プロダクションコードへの新たなメソッドの追加は不要になり、LegacyProxyクラスに定義された関数は再利用されることになります。また、DIコンテナとの統合も問題ありません。
関数と同じように定数もレガシープロキシーで置き換えることができます。最初にLegacyProxyクラスに以下のようなメソッドを追加します。メソッド名は定数と同じにしておきます。
<?php
...
class LegacyProxy
{
...
public function PHP_OS()
{
return PHP_OS;
}
...
次にプロダクションコードを書き換えます。
<?php
...
class OS
{
...
protected $legacyProxy;
...
public function setLegacyProxy(LegacyProxy $legacyProxy)
{
$this->legacyProxy = $legacyProxy;
}
...
public function isWin()
{
return strtolower(substr($this->legacyProxy->PHP_OS(), 0, strlen('win'))) == 'win';
}
...
レガシープロキシーを導入することで関数や定数を使ったコードのテスト容易性（testability）を高めることができます。関数・定数が多用された古いコードの改善においても大いに役立つことでしょう。
Symfonyの機能テストでは最初にWebTestCase::createClient()メソッドでClientオブジェクトを作成し、そのオブジェクトを使ってリクエストを行い、その返り値を確認することによってテストを行います。
テストクラス:
<?php
...
class ...Test extends WebTestCase
{
public function test...()
{
$client = static::createClient();
$client->request('GET', '/path/to/foo');
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('入力ページ'));
...WebTestCase::createClient()メソッドは内部でDIコンテナを初期化するため、Clientオブジェクト作成後にモックオブジェクトをサービスのインスタンスとして設定することができます。
テストクラス:
<?php
...
class ...Test extends WebTestCase
{
public function test...()
{
$client = static::createClient();
// モックオブジェクトを構成し、サービスのインスタンスとして設定する。
$entityManager = \Phake::mock('Doctrine\ORM\EntityManager');
\Phake::when($entityManager)->...
...
$client->getContainer()->set('doctrine.orm.default_entity_manager', $entityManager);
$client->request('GET', '/path/to/foo');
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('入力ページ'));
...ここまでは何の問題もありません。さて、ここから正常系のページフロー全体のテストへ拡張することを考えます。入力・確認・完了のページフローの場合、2回目のリクエストはフォームの送信になります。
テストクラス:
<?php
...
class ...Test extends WebTestCase
{
public function test...()
{
...
$client->request('GET', '/path/to/foo');
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('入力ページ'));
$form = $client->getCrawler()->selectButton('next')->form();
$form['foo'] = ...
$client->submit($form);
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('確認ページ'));
...残念ながらこのテストは失敗します。これはClient::submit()メソッドでDIコンテナを含む実行環境が初期化されることが原因です。WebTestCase::createClient()メソッドとは異なりモックオブジェクトを設定するタイミングもありません。
ではWebTestCase::createClient()メソッドを再度実行することで解決できるかというとそうはいきません。この場合はリクエストの度にセッションが異なるため、フォームのCSRFトークンなどが障害になりページフローのテストは困難になります。ページフローをテストするためにはあくまでも同一のClientオブジェクトを使う必要があります。
この問題を解決する一つの手段はイベントディスパッチャーです。例えばBundle::boot()メソッドで独自のイベントを発生させるようにします。
バンドルクラス:
<?php
...
class ...Bundle extends Bundle
{
public function boot()
{
...
foreach (BundleEvent::getPostBootListeners() as $postBootListener) {
$this->container->get('event_dispatcher')->addListener(BundleEvent::POST_BOOT, $postBootListener);
}
$this->container->get('event_dispatcher')->dispatch(BundleEvent::POST_BOOT, new BundleEvent($this->container));
}
public function shutdown()
{
foreach (BundleEvent::getPostBootListeners() as $postBootListener) {
$this->container->get('event_dispatcher')->removeListener(BundleEvent::POST_BOOT, $postBootListener);
}
}
...BundleEventクラスはイベントリスナーの登録とDIコンテナの保持のために用意したクラスです。テストクラスではリクエストの前後でイベントリスナーを登録・削除するようにします。
テストクラス:
<?php
...
class ...Test extends WebTestCase
{
protected function addPostBootListeners(array $postBootListeners)
{
foreach ($postBootListeners as $postBootListener) {
BundleEvent::addPostBootListener($postBootListener);
}
}
protected function removePostBootListeners(array $postBootListeners)
{
foreach ($postBootListeners as $postBootListener) {
BundleEvent::removePostBootListener($postBootListener);
}
}
public function test...()
{
$postBootListeners = array(...);
$this->addPostBootListeners($postBootListeners);
$client = static::createClient();
$this->removePostBootListeners($postBootListeners);
...
$client->request('GET', '/path/to/foo');
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('入力ページ'));
$form = $client->getCrawler()->selectButton('next')->form();
$form['foo'] = ...
$postBootListeners = array(...);
$this->addPostBootListeners($postBootListeners);
$client->submit($form);
$this->removePostBootListeners($postBootListeners);
$this->assertEquals(200, $client->getResponse()->getStatusCode());
$this->assertThat($client->getCrawler()->filter('title')->text(), $this->stringContains('確認ページ'));
...これで無事に2回目以降のリクエストでもモックオブジェクトを使えるようになりました。
PHPメンターズの後藤です。クリスマスまでの24日間をSymfonyの記事で楽しもう！というSymfony Advent Calendar JP 2011の16日目の記事です。前回はSymfony2のテストコードを読むにてSymfonyのHttpKernelコンポーネントにあるKernelクラスのテストコードを紹介し、PHPUnitのモックオブジェクトを使っている例を説明しました。
今回は、前回紹介したテストコードを、PHPのモッキングフレームワークであるPhakeを使って書き換えてみましょう。
SymfonyのテストでPhakeを使うための準備については、こちらの記事を参照してください。
まず、前回取り上げたテストコードを最初に再掲します。
tests/Symfony/Tests/Component/HttpKernel/KernelTest.php:
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel = $this->getMockBuilder('Symfony\Tests\Component\HttpKernel\KernelForTest')
->disableOriginalConstructor()
->setMethods(array('initializeBundles', 'initializeContainer', 'getBundles'))
->getMock();
$kernel->expects($this->once())
->method('initializeBundles');
$kernel->expects($this->once())
->method('initializeContainer');
$kernel->expects($this->once())
->method('getBundles')
->will($this->returnValue(array()));
$kernel->boot();
}
このコードにおけるテストの意図を、Phakeを使って順に再現します。まず最初は、テスト対象であるboot()メソッドの呼び出しを記述します。
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel->boot();
}
$kernelを用意しなければなりません。このテストでは、同じクラスの別メソッドを呼び出すという振舞をテストしたいため、Kernelの実オブジェクトではなく、純粋なモックオブジェクトでもなく、パーシャルモックオブジェクトを利用します。
※PHPUnitのテストコードで作成しているのも、同じようにパーシャルモックオブジェクトです。
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel = \Phake::partialMock('Symfony\Tests\Component\HttpKernel\KernelForTest', 'env', true);
$kernel->boot();
}
基本的な準備はこれで整いましたが、これでは何もテストしていません。元のテストコードでテストしていたboot()メソッドの振る舞いである、initializeBundles(), initializeContainer(), getBundles()メソッドが呼び出されていることを検証するテストコードを追加しましょう。このようなメソッド呼び出しの検証には、Phake::verifyを使います。
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel = \Phake::partialMock('Symfony\Tests\Component\HttpKernel\KernelForTest', 'env', true);
$kernel->boot();
\Phake::verify($kernel)->initializeBundles();
\Phake::verify($kernel)->initializeContainer();
\Phake::verify($kernel)->getBundles();
}
このようにboot()メソッドを実行した後、実際に各メソッドが呼び出されたことを検証(verify)するように記述します(ここではそれぞれ1回ずつ呼び出されたことを検証しています)。
これでよさそうにも見えますが、このテストではinitializeBundles(), initializeContainer(), getBundles()それぞれの実装には触れたくありません。ですので、これらの3つのメソッドをモックで置き換えます。メソッドをモックで置き換えるには、Phake::whenを使います。
class KernelTest extends \PHPUnit_Framework_TestCase
{
// snip
public function testBootInitializesBundlesAndContainer()
{
$kernel = \Phake::partialMock('Symfony\Tests\Component\HttpKernel\KernelForTest', 'env', true);
\Phake::when($kernel)->initializeBundles()->thenReturn(null);
\Phake::when($kernel)->initializeContainer()->thenReturn(null);
\Phake::when($kernel)->getBundles()->thenReturn(array());
$kernel->boot();
\Phake::verify($kernel)->initializeBundles();
\Phake::verify($kernel)->initializeContainer();
\Phake::verify($kernel)->getBundles();
}
これで完成です。最初のコードと見比べてみてください。このテストメソッドでテストしている内容と意図を、コードから明確に読み取れるようになっていることが分かります。
モックオブジェクトを使うことで、テストしたい対象だけに焦点を絞ることができるようになりますが、Phakeのように、よりしなやかに開発者の意図を記述できるフレームワークを利用することで、読みやすくメンテナンス性の高いテストコードを書くことができます。
このようにしてテストコードに開発者の意図が反映しやすくなることは、ドメインモデルの改善やブレイクスルーにもつながります。
以前のSymfony勉強会の折にユニットテストとモックの話をさせていただいたのですが、その時に@cakephperさんから次のような意見を頂いていました。
APIを信用して基本Mockでという話、API側の仕様変更を常にウォッチしてないといけないのでフレームワークのアップデートとか大変なんじゃないのかなと思ったんだけど、そこんとこまだ消化できてない
twitter - @cakephper
まず最初に回答としては「APIが変わるのであれば概ねそのとおり」となります。しかし、これはモックを使うかどうかには関係ありません。ソフトウェアはフレームワークやライブラリ等サードパーティコードの仕様変更に常に影響を受けます。ここで、議論の前提を共有しておく必要があるでしょう。
前提として、ユニットテストの方がファンクショナルテストよりも「気軽に書ける」「局所的な仕様を確認できる」ものだという点があります。TDD等を適用して継続的にソフトウェアを開発・成長させて行く場面では、個別のメソッドのロジックを局所的にユニットテストで検証できることを重要視しています。
これは、ファンクショナルテストが不要ということではありません。役割が違うということです。
書籍『実践テスト駆動開発』の第8章「サードパーティーコードの上に構築する」にて、「モックするのは自分の持っている型だけ」という節がでてきます。ここには次のように書かれています。
ふたつめのリスクは、私たちがスタブやモックで作り出す振る舞いを外部ライブラリの実際の振る舞いと正確に合致させなければならない点にある。これがどの程度難しいかは、扱うライブラリの質に依存する。私たちの書いたユニットテストが妥当であると自信を持って言えるくらいに分かりやすく説明されているか（そして、実装されているか）ということだ。いったん正しい状態に持っていったとしても、ライブラリをアップグレードする際には、テストが変わらず正しく動いていることを確認しなければならない。
実践テスト駆動開発 - p74 自分たちで変更できない型をモックしてはならない
自分の持っている型というのは、自分が書いたクラスということですね。外部のものに対して、基本的にはモックにしないということです。ただし、ここで前提となっているのはサードパーティコードのAPIの安定性がそれほど高いとは言えない場合です。この場合の対処として、実践テスト駆動開発ではアダプターレイヤーを作るよう書かれています。サードパーティコードの不安定性をアダプターレイヤーで吸収するわけです。これは、SOLID原則でいう依存関係逆転の原則（DIP）、および安定したパッケージへ依存するようにする安定依存の原則（SDP）を適用するということでもあります。
Note ここでいうAPIの安定性とは、ライブラリメソッド等の入出力仕様の安定度を指します。
サードパーティのコードといえども、フレームワークやORMのようにインフラとして利用するコードの場合、一般的にはAPIの安定性は高いとみなせます。この場合、ユニットテストではサードパーティコードのオブジェクトを直接モックして使ってもよいでしょう。サードパーティコードのAPI変更については、自分の持っているクラスに対するファンクショナルテスト（インテグレーションテスト）でカバーします。この場合でも、テストする基準は自分の持っているクラスであり、サードパーティコードの仕様を網羅的にテストするわけではありません（テスト作成にかけられる手間やコストとも関係します）。
PHPメンターズのユーザー登録サンプルアプリケーションで、ドメインレイヤーのUserRegistrationServiceクラスのテストコードを例として紹介します。register()メソッドでユーザーを登録するユースケースシナリオを実行しますが、その時にインフラとして次の 3 つを利用しています。
EntityManagerは実クラスですが、ここは Doctrine\Common\Persistence\ObjectManager（インターフェイス）と同義です。このテストでは PasswordEncoderInterface 等のインターフェイスをモックして使っています。もちろん、PasswordEncoderInterface の実装の動作が将来変更になる可能性はゼロではありませんが、このユニットテストでテストしたいのは PasswordEncoder の結果ではなく、「register() メソッドが PasswordEncoder を使ってパスワードを生成していること」です。ですので、モックを使ってインタラクションをテストしているのです。
class UserRegistrationServiceTest extends ComponentAwareTestCase
{
/**
* @test
*/
public function ユーザーを登録する()
{
$userClass = 'Example\UserRegistrationBundle\Domain\Data\User';
$userRepository = \Phake::mock('Example\UserRegistrationBundle\Domain\Data\Repository\UserRepository');
$password = 'PASSWORD';
$user = \Phake::mock($userClass);
\Phake::when($user)->getPassword()->thenReturn($password);
$entityManager = \Phake::mock('Doctrine\ORM\EntityManager');
\Phake::when($entityManager)->getRepository($userClass)->thenReturn($userRepository);
$this->setComponent('example_user_registration.entity_manager', $entityManager);
$passwordEncoder = \Phake::mock('Symfony\Component\Security\Core\Encoder\PasswordEncoderInterface');
\Phake::when($passwordEncoder)->encodePassword($this->anything(), $this->anything())->thenReturn($password);
$this->setComponent('example_user_registration.password_encoder', $passwordEncoder);
$activationKey = 'ACTIVATION_KEY';
$secureRandom = \Phake::mock('Symfony\Component\Security\Core\Util\SecureRandomInterface');
\Phake::when($secureRandom)->nextBytes($this->anything())->thenReturn($activationKey);
$this->setComponent('security.secure_random', $secureRandom);
$userTransfer = \Phake::mock('Example\UserRegistrationBundle\Domain\Data\Transfer\UserTransfer');
\Phake::when($userTransfer)->sendActivationEmail($this->anything())->thenReturn(true);
$this->setComponent('example_user_registration.user_transfer', $userTransfer);
$this->createComponent('example_user_registration.user_registration_service')->register($user);
\Phake::verify($secureRandom)->nextBytes($this->isType(\PHPUnit_Framework_Constraint_IsType::TYPE_INT));
\Phake::verify($user)->setActivationKey($this->equalTo(base64_encode($activationKey)));
\Phake::verify($user)->getPassword();
\Phake::verify($passwordEncoder)->encodePassword($this->isType(\PHPUnit_Framework_Constraint_IsType::TYPE_STRING), $this->isType(\PHPUnit_Framework_Constraint_IsType::TYPE_STRING));
\Phake::verify($user)->setPassword($this->isType(\PHPUnit_Framework_Constraint_IsType::TYPE_STRING));
\Phake::verify($user)->setRegistrationDate($this->isInstanceOf('DateTime'));
\Phake::verify($userRepository)->add($this->identicalTo($user));
\Phake::verify($entityManager)->flush();
\Phake::verify($userTransfer)->sendActivationEmail($this->identicalTo($user));
}
}
実際のところ、サードパーティライブラリの安定度を個別に全て、使う前に評価するというのも難しいことです。ある程度信頼できるフレームワークであればまずはユニットテストなどではモックする。運用していく中で壊れやすい部分が判明した時点で、アダプターレイヤー等を設け安定性を確保する、という方針が現実的でしょう。
Q.「フレームワークのAPI変更を細かくウォッチしていなければいけないのか？」
A. 前述のように、モックを使おうが使うまいが、フレームワークやライブラリ等のサードパーティコードの仕様変更に対応しなければならないことに変わりはありません。ユニットテストを修正する分の手間は増えますが、モックによって自身のコードのロジックに焦点を絞ることができるメリットはそれを補って余りあると考えています。
モックするのは自分の持っている型だけ 『実践テスト駆動開発』 p.74〜「自分たちで変更できない型をモックしてはならない」「アダプタ層を書く」
この書籍では、モックを使ったTDDについて詳細かつ実践的な解説が書かれています。 依存関係逆転の原則 DIP：Dependency Inversion Principle 『アジャイルソフトウェア開発の奥義 第2版』 p.163〜 安定依存の原則 SDP：Stable Dependencies Principle 『アジャイルソフトウェア開発の奥義 第2版』 p.325〜
Phakeは、PHPのテストコードでモックオブジェクトを扱うためのフレームワークです。既存のテスティングフレームワークのアサーション等とは独立して、モックオブジェクトを使ったテストを組み込むことができます。
Symfony2の本体のテストコードを例に、Phakeを使えるようにする手順を説明します。ここでは既にSymfony2のコードが手元にあるものとします。
PhakeのドキュメントではPEARによるインストール方法で説明されていますが、この記事ではプロジェクトローカル、つまりプロジェクト配下のvendorディレクトリにPhakeのファイルを配置したいので、gitを使ってGitHubからリポジトリをcloneします。
$ git clone git://github.com/mlively/Phake.git vendor/phake
PEARでインストールした場合は不要ですが、プロジェクトローカルに配置した場合はインクルードパスにPhakeのディレクトリを追加しておく必要があります。同時にPhakeをrequire_onceし、PHPUnit用のフラグも設定します。
Symfony本体のテストコードでは、ブートストラップスクリプト(起動スクリプト)としてtests/bootstrap.phpファイルが用意されていますので、このファイルの末尾に次のコードを追加してください。
tests/bootstrap.php:
<?php
// snip
set_include_path(get_include_path().PATH_SEPARATOR
.__DIR__.'/../vendor/phake/src/');
require_once 'Phake.php';
\Phake::setClient(\Phake::CLIENT_PHPUNIT);
これで、PHPUnitのテストメソッド内で、次のようにモックオブジェクトを扱えるようになります。
$request = \Phake::mock('Request'); // Requestクラスのモックオブジェクトを作成
TL;DR
ユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト（依存オブジェクト、隣接オブジェクト）はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。
簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておらず、グループに所属するメンバーについての情報は、かならずグループリポジトリに問い合わせるような作りになっている、という前提とします。グループリポジトリは、次の2つのメソッドを持つインターフェイスで定義されています。
interface GroupRepository
{
/**
* @param Group $group
* @return Member[]
*/
public function membersInGroup(Group $group);
/**
* @param Member $member
* @param Group $group
*/
public function addMemberToGroup(Member $member, Group $group);
}
このグループにメンバーを追加するユースケースを実装し、対応するテストも実装したいとしましょう。
グループには「3名までしか所属できない」というビジネスルールがあります。すでに所属しているメンバーの数が3以上なら例外をスローします。
class JoinGroupUseCase
{
/**
* @var GroupRepository
*/
private $groupRepository;
/**
* @param GroupRepository $groupRepository
*/
public function setGroupRepository($groupRepository)
{
$this->groupRepository = $groupRepository;
}
/**
* @param Member $member
* @param Group $group
* @throws \RuntimeException
*/
public function run(Member $member, Group $group)
{
if (count($this->groupRepository->membersInGroup($group)) >= 3){
throw new \RuntimeException('グループにこれ以上追加できません');
}
$this->groupRepository->addMemberToGroup($member, $group);
}
}
run()メソッドで例外が発生するパスをテストするには、GroupRepositoryをモックし、membersInGroup()メソッドで3人のメンバーを返せばよいですね。
class JoinGroupUseCaseTest extends \PHPUnit_Framework_TestCase
{
/**
* @var Group
*/
private $group;
/**
* @var Member
*/
private $member1;
/**
* @var Member
*/
private $member2;
/**
* @var Member
*/
private $member3;
/**
* @var Member
*/
private $member4;
/**
* @var
*/
private $groupRepository;
/**
* @var JoinGroupUseCase
*/
private $SUT;
/**
* @test
*/
public function 正常フロー()
{
$this->groupRepository->expects($this->once())
->method('membersInGroup')
->with($this->equalTo($this->group))
->will($this->returnValue([
$this->member2,
]));
$this->groupRepository->expects($this->once())
->method('addMemberToGroup')
->with($this->equalTo($this->member1), $this->equalTo($this->group));
$this->SUT->run($this->member1, $this->group);
}
/**
* @test
* @expectedException RuntimeException
*/
public function 例外フロー()
{
$this->groupRepository->expects($this->once())
->method('membersInGroup')
->with($this->equalTo($this->group))
->will($this->returnValue([
$this->member2,
$this->member3,
$this->member4,
]));
$this->groupRepository->expects($this->never())
->method('addMemberToGroup');
$this->SUT->run($this->member1, $this->group);
}
protected function setUp()
{
$this->groupRepository = $this->getMock(GroupRepository::class);
$this->group = $this->getMock(Group::class);
$this->member1 = $this->getMock(Member::class);
$this->member2 = $this->getMock(Member::class);
$this->member3 = $this->getMock(Member::class);
$this->member4 = $this->getMock(Member::class);
$this->SUT = new JoinGroupUseCase();
$this->SUT->setGroupRepository($this->groupRepository);
}
}
これでユニットテストを記述できました。テストもパスします。しかしこれでは、テストコードの面からも、ドメインオブジェクトの面からも望ましくない点があります。
テストしたいパスのための前提条件を整えるために、複雑なオブジェクトの組み合わせ全体＝オブジェクトの状態をモックにより再現しているということです。これは、モックが複雑になるばかりでなく、脆いテストにもなってしまいます。
問題を改善するための最初のステップは、ビジネスルールを表していた部分をメソッドに抽出して明示的に表現することです。今回は「グループには3人までしか追加できない」というルールでした。グループにメンバーを追加するユースケースで知りたいのは、グループに所属しているメンバーの人数そのものではなくて、「追加できるのかどうか」つまり「グループが一杯かどうか」ということです。これを直接表すように、リポジトリのメソッドとして groupIsFull() を追加します。
interface GroupRepository
{
...
/**
* @param Group $group
* @return bool
*/
public function groupIsFull(Group $group);
}
このメソッドを使って条件を判定するようにユースケースメソッドを変更します。
class JoinGroupUseCase
{
...
/**
* @param Member $member
* @param Group $group
* @throws \RuntimeException
*/
public function run(Member $member, Group $group)
{
if ($this->groupRepository->groupIsFull($group)){
throw new \RuntimeException('グループにこれ以上追加できません');
}
$this->groupRepository->addMemberToGroup($member, $group);
}
}
テストコードでは、GroupRepository#groupIsFull()メソッドをモックすることで前提条件をシンプルに制御できるようになります。
class RefinedJoinGroupUseCaseTest extends \PHPUnit_Framework_TestCase
{
/**
* @var Group
*/
private $group;
/**
* @var Member
*/
private $member1;
/**
* @var
*/
private $groupRepository;
/**
* @var JoinGroupUseCase
*/
private $SUT;
/**
* @test
*/
public function 正常フロー()
{
$this->groupRepository->expects($this->once())
->method('groupIsFull')
->with($this->equalTo($this->group))
->will($this->returnValue(false));
$this->groupRepository->expects($this->once())
->method('addMemberToGroup')
->with($this->equalTo($this->member1), $this->equalTo($this->group));
$this->SUT->run($this->member1, $this->group);
}
/**
* @test
* @expectedException RuntimeException
*/
public function 例外フロー()
{
$this->groupRepository->expects($this->once())
->method('groupIsFull')
->with($this->equalTo($this->group))
->will($this->returnValue(true));
$this->groupRepository->expects($this->never())
->method('addMemberToGroup');
$this->SUT->run($this->member1, $this->group);
}
protected function setUp()
{
$this->groupRepository = $this->getMock(GroupRepository::class);
$this->group = $this->getMock(Group::class);
$this->member1 = $this->getMock(Member::class);
$this->SUT = new JoinGroupUseCase();
$this->SUT->setGroupRepository($this->groupRepository);
}
}
修正したユースケースメソッドとテストコードからは、グループが一杯かどうかについての判定の詳細が現れていません（3人なのかどうか）。条件そのものをメソッドに抽出したことで一段階抽象化が行われ、プロダクションコードからは抽象的に表現された条件を使うようになりました。ユースケースのテストコードでは、各条件の詳細に立ち入ることなく、抽象的に前提条件を整えるだけでよくなり、テストしたいフローに集中できます。これにより、グループが一杯かどうかという条件の中身が変更されても、ユースケースのプロダクションコードとテストコードを変更する必要はありませんし、テストが壊れることはなくなります。また、プロダクションコードもテストコードもシンプルになります（モックするオブジェクトも少なくなります）。
ユビキタス言語を反映してドメインオブジェクトを豊かに育てると、プロダクションコードもテストコードもシンプルになります。壊れにくい頑強なドメインモデルとテストを作っていくことができます。DDDはこのようにコードをシンプルにする効果があると言えます。
現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。
<?php
...
class OrderService
{
...
public function order(Order $order)
{
$currentHour = (integer) (new \DateTime())->format('H');
if ($currentHour >= 10 && $currentHour < 21) {
...
} else {
throw new OrderException('ご注文は午前10時から午後9時まで！');
}
}
...
実際の現在の時刻に依存せずにif文の条件をテストする1つの方法は、DataTimeオブジェクトの生成部分をメソッドとして抽出し、そのメソッドの呼び出しをモックで置き換えることです。この場合プロダクションコードは以下のようになります。
<?php
...
class OrderService
{
...
public function order(Order $order)
{
$currentHour = (integer) $this->createDateTime()->format('H');
if ($currentHour >= 10 && $currentHour < 21) {
...
} else {
throw new OrderException('ご注文は午前10時から午後9時まで！');
}
}
...
protected function createDateTime()
{
return new \DateTime();
}
...
モッキングフレームワークPhakeを使った場合のテストコードは以下のようになります。
<?php
...
class OrderServiceTest extends \PHPUnit_Framework_TestCase
{
/**
* @test
*/
public function 営業時間内は注文を受け付ける()
{
...
$orderService = \Phake::partialMock('...\OrderService');
\Phake::when($orderService)->createDateTime()->thenReturn(new \DateTime('2013-04-01 10:00:00'));
$orderService->order($order);
...
}
/**
* @test
*/
public function 営業時間外は例外を発生させる()
{
...
$orderService = \Phake::partialMock('...\OrderService');
\Phake::when($orderService)->createDateTime()->thenReturn(new \DateTime('2013-04-01 21:00:00'));
try {
$orderService->order($order);
$this->fail('期待通りの例外が発生しませんでした。');
} catch (OrderException $e) {
}
}
}
以前の記事「関数・定数のラッパーオブジェクト（レガシープロキシー）を導入してテスト容易性を高める」ではこの方法の問題点について解説しました。
このように関数の呼び出しをメソッドの呼び出しに置き換えることで、部分的にモックが適用されたオブジェクト（パーシャルモック）を使ったテストが可能になります。
この方法の問題点はテストの都合によってプロダクションコードの変更が必要になることです。例え同じ関数であったとしても、クラスが異なれば再度同じことを行う必要があります。加えてパーシャルモックはDIコンテナとの統合が難しいため、テストコードにオブジェクトの構成の知識が流出することになります。
もう1つの方法はアプリケーション専用の時計オブジェクト（私はドメインクロックと呼んでいます。）を導入することです。最初に以下のようなクラスを用意します。
<?php
...
class Clock
{
public function hour()
{
return (integer) (new DateTime()).format('H');
}
}
ここでは現在の時間を返すhour()メソッドを定義しています。次にClockオブジェクトを使ってプロダクションコードを書き換えます。
<?php
...
class OrderService
{
...
protected $clock;
...
public function __construct(Clock $clock)
{
$this->clock = $clock;
}
...
public function order(Order $order)
{
$currentHour = $this->clock->hour();
if ($currentHour >= 10 && $currentHour < 21) {
...
} else {
throw new OrderException('ご注文は午前10時から午後9時まで！');
}
}
...
最後にテストコードを書き換えます。先ほどのパーシャルモックの代わりにClockオブジェクトをモックオブジェクトで置き換えます。
<?php
...
class OrderServiceTest extends \PHPUnit_Framework_TestCase
{
/**
* @test
*/
public function 営業時間内は注文を受け付ける()
{
...
$clock = \Phake::mock('...\Clock');
\Phake::when($clock)->hour()->thenReturn(10);
$orderService = new OrderService($clock);
$orderService->order($order);
...
}
/**
* @test
*/
public function 営業時間外は例外を発生させる()
{
...
$clock = \Phake::mock('...\Clock');
\Phake::when($clock)->hour()->thenReturn(21);
$orderService = new OrderService($clock);
try {
$orderService->order($order);
} catch (OrderException $e) {
return;
}
$this->fail('期待通りの例外が発生しませんでした。');
}
}
この方法では、プロダクションコードへの新たなメソッドの追加は不要になります。また、DIコンテナとの統合も問題ありません。
ドメインクロックはドメイン駆動設計（DDD: Domain-Driven Design）のビルディングブロック（エンテイティ、リポジトリ、ファクトリ等）と同様に定義済みのモデルと考えることができます。
ドメインクロックを導入することで現在の時刻を扱うコードのテスト容易性（testability）を高めることができます。加えて、こちらの方が重要なことですが、Clockクラスに依存するクラスが現在の時刻を扱うことは明白であるため、コードの意図性（intentionality）も同時に高めることができるのです。
先週になりますが、MakeGoodのメジャーアップデートとなるバージョン2.0.0をリリースしました。具体的な変更点はリリースノートをご覧いただくとして、本記事では改めてMakeGoodについて簡単に解説したいと思います。
MakeGoodは継続的テスト（Continuous Testing）と呼ばれるプラクティスに基づいたユニットテスト実行環境であり、Eclipse PDT上で動作します。MakeGoodの中心にあるテーマは素早いフィードバックです。それは主にファイル保存時のテストの実行と失敗・エラー・致命的なエラーの自動的な追跡による、テスト実行ワークフローの自動化として表現されています。ここでいうテスト実行ワークフローとは以下のようなものです。
MakeGoodでは上記のワークフローが自動化されており、また極力目立たないように動作するため（画面右下の緑色の四角を見てください！）、開発者はエディタ上のプログラミングに集中することができます。
継続的テストとは、開発者のマシン上でファイルが保存される度にバックグラウンドで自動的にテストを実行することによって、テストの失敗に関する迅速なフィードバックを提供しようとするものです。
最初に継続的テストを提唱したMITのProgram Analysis Groupの研究によると、継続的テストによって以下のような結果が得られたとされています。
Object Mentorのブログ記事Continuous Testing Explainedでは、このような結果は以下の効果からきていると述べられています。
継続的インテグレーション（Continuous Integration）によるテストとの違いは、フィードバックの速さです。継続的テストではファイルを保存すると、数秒で結果が得られます。また、継続的テストが開発者個人のプログラミングの活動にフォーカスしていることも違いといえるでしょう。
継続的テストによる素早いフィードバックの恩恵を最大にするには自動的なテストの実行だけでは十分ではありません。テストが失敗した際にその原因を探る時間は馬鹿になりません。例えば、多くのコマンドラインツールでは、どのファイルの何行目のアサーションが失敗したのかを特定するには目視に頼る他はありません。また、特定したファイルをテキストエディタで開き、該当行に移動するのも手間がかかるでしょう。MakeGoodを使えばこのプロセスは瞬時に完了します。素早いフィードバックを標榜する開発者であれば、このオーバーヘッドを無視することはできないでしょう。
また、MakeGoodでは結果ツリーやスタックトレースからのクラス、メソッド、ファイルへのジャンプもサポートしていますので、Eclipse PDTの機能と合わせて素早く原因を探ることができます。これらはもちろんコマンドラインツールとテキストエディタで実現できないことではありませんが、同等の環境を構築するには相当の困難を伴うことは想像に難くありません。
MakeGoodに限らず、プログラミングにおいて適切なツールを使うことは、開発者がプログラミングそのものに注力するためにとても重要なことです。思慮深い開発者であれば、置かれた状況にとって適切なツールを好みや固執を乗り越えて選択することができるでしょう。
MakeGoodは今後とも素早いフィードバックを原則として開発を進めていきます。まだ使ったことがない方も是非一度お試しください。きっと気に入っていただけると確信しています。
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シャツにも注目しながら、ぜひご覧ください。
全体の流れとしては、1980年代以降のソフトウェア開発の歴史を、主にオブジェクト指向に対する考え方の変遷を通して振り返りつつ、MPD と DCI の関係性に迫るものとなりました。
当時は C++ の他に、テレコム業界向け言語である CHILL や、軍需産業向け言語である Ada などの言語があり、それらの言語がオブジェクト指向なのかという議論がされていました。
最終的に C++ が残ることになりますが、C++ の作者である Stroustrup 氏は、そもそも C++ をオブジェクト指向言語ではなく、マルチパラダイム言語と定義していたことに注意する必要があります。
当時考えられていたオブジェクト指向の構成要素は次の3項目でした。
1994年に Coplien さんは David Weiss 氏と Robert Chi Tao Lai 氏とともに仕事をしますが、その時、共通性／可変性分析を通じて、ソフトウェアファミリの振る舞いなどを特徴づけ、当時取り組んでいたソフトウェアのための DSL(Domain Specific Language) を開発しました。開発言語は C でした。
この、共通性に注目してグルーピングしたものをファミリと定義する方法は、Weiss 氏らが考案したFAST(Family Abstraction Specification Technique) という手法に基づいています。
DSL は小さなドメインを対象にしていて、ドメインが変化しない限りはうまくいったそうですが、ドメインは変化していくものです。DSL は、デバッガなど周辺技術との密な関係性の中で成立するため、その変化に対しては脆いという問題がありました。
ただし、共通性／可変性分析自体は非常に有用で、ドメイン分析に対しては非常に多くの収穫があったそうです。
分析の結果得られる共通性／可変性テーブルの内容の埋め込み（注: 解決ドメインの抽象による実装）に関して、
という課題がありましたが、C++ を用いることで、よりうまくいくようになりました。
Coplien さんは、C++ を
共通性／可変性分析のための、汎用言語キットである
と捉えます。
その視点で見たオブジェクト指向は、次の4項目の構成要素で理解されるようになりました。
また、polymorphism / instantiation は、共通性／可変性のバインディングタイム（注: 共通性／可変性が変数に束縛されるタイミング）の選択の問題として捉え直されることになりました。
Coplien さんによれば、更にこの後、3段階の気付きを経て、現在のオブジェクト指向理解へとつながっているそうです。
MPD は、クラス指向のレイヤーにおいてドメイン分析を行う時、ソフトウェアファミリの共通性／可変性分析を通じてドメインモデルを構築する手法を提供します。
DCI は、我々のメンタルモデルに基づいて、オブジェクトどうしの相互作用を定義します。そこでは、抽象データ型としてのクラスに具体的なロールを注入されたオブジェクトが、特定のコンテキストのもとに配置され、相互作用するという、動的な側面を捉える方法を提供します。
以上を簡単にまとめると、次の表のようになるかと思います。
| パラダイム | 設計対象 | 領域 | 手段 | 視点 |
|---|---|---|---|---|
| DCI | オブジェクトとそれらの相互作用 | ロール / コンテキスト | ユースケース | Time |
| MPD | 抽象データ型、モデルの構造 | クラス / Abstract Base Class (ABC) | 共通性／可変性分析 | Space |
歴史的には MPD が先行しました。それは後に、モデルの静的な構造の分析を行うための領域を担う設計方法論という捉え直しがされました。そして、オブジェクト指向に対する新しい視点を提供する DCI が、クラス指向では扱うことが難しかった、モデルの動的な関係性を捉えるための方法論として提起されています。
DCI は、オブジェクトどうしの相互作用に注目します。つまり基本的には時間の経過（シーケンス）が意識されます。しかし、あるロールを付与された複数のオブジェクトが配置されてこそ、相互作用が成立するものです。
コンテキストとは、このように、ある状況に参加する主体の空間的配置と時間的な相互作用の総体として捉えられるものと言えます。
ここで、日本人にとってはありふれた「間」という概念が取り上げられました。具体例としては次のようなものが話題にあがりました。
また、アレグザンダーの考案したパターンランゲージに話が及びました。パターンランゲージは、建築の構造（空間的なパターン）だけではなく、その構造が生み出す人々の相互作用（時間的なパターン）も内包したものとして理解されるべきです。
pattern of behavior = pattern in space + pattern in time
セッションの終盤では、このように、DCI が担う領域における共通性／可変性概念の適用可能性が示唆されました。
会場を提供していただきましたヴァル研究所様、DCI Tokyo スタッフの皆様、今回もすばらしいイベントとなりました。ありがとうございました。
次回は、ワークショップ形式での開催も視野に入れながら、DCI Tokyo 3 が開催されることと思います。MPD / DCI / Lean Architecture に興味のある方は、ぜひご参加ください。