Practical Symfony #20: PHPUnit、Stagehand_TestRunner、MakeGoodに対応したユニットテスト実行環境の構築

本ブログではこれまで「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ベースのユーザー登録サンプル

PHPメンターズ プログラミング道場 入門生募集終了

先日ご案内した「PHPメンターズ プログラミング道場」について、2名の方から入門希望のご連絡をいただきましたので、今回はこれで募集を終了とさせていただきます。

入門生には、学んだ内容を本ブログの記事としてアウトプットします。記事が公開された折には、読者の皆さんからのご意見ご指導も遠慮なく頂きたく思っております。入門生の記事も合わせまして、今後ともPHPメンターズブログの購読をよろしくお願いいたします。

6月1日(土) PHPカンファレンス関西2013で基調講演とセッションを行います

6月1日(土)に大阪産業創造館でPHPカンファレンス関西2013が開催されます。

今回、久保は「意図を表現するプログラミング」と題して基調講演を行います。また、後藤は「関心を分離するってどういうこと？」と題するセッションを行います。これらの講演を通じて、私たちが日常的に考えていることを多くの人にわかりやすくお伝えできればと考えております。

10:40-11:20 基調講演 意図を表現するプログラミング 久保 敦啓

私自身のオープンソース開発者としての活動を、Piece Frameworkの開発や、関西コミュニティとの関わりを中心に振り返りながら、個人的・全体的な関心の変遷について見ていきます。そして現在の私の関心である「意図を表現するプログラミング」についてお話しします。

14:30-14:50 セッション 関心を分離するってどういうこと？ 後藤 秀宣

継続的に成長を続けられるソフトウェアを開発するために、関心が適切に分離されていることが重要です。関心の分離とはそもそもどういうことなのかを、Webプログラマー向けに易しく解説します。また、関心の分離を適切に扱うための概念やパターン、アーキテクチャーなども紹介します。

是非ご参加ください！

PHPカンファレンス関西2013のプログラムには、幅広い客層に対応する魅力的なセッションが目白押しです。是非多くの方にご参加いただきたいと思います。

最近Eclipse PDTを拡張するプラグインThe PDT Extension Group Core Pluginでリファクタリング機能の追加に取り組んでいることもあり、私は山本祐介さん（@yusuke）のセッション「PhpStormで始まるキモチイイPHP開発」が気になっています。

では、当日皆様にお会いできることを楽しみにしております。

参考

• PHPカンファレンス関西2013

PHPメンターズ プログラミング道場

PHPメンターズではPHPプログラマーコミュニティ向けの活動の一環として、「PHPメンターズ プログラミング道場」を開始します。

5/15 入門生の募集は終了しました。

以下のような内容になります。

• 対象者
  • プログラマーとして生き残っていける技術・知識を身に付けたい方
• 内容
  • メンターとのSkypeミーティング（各種技術トピック、テーマ書籍に関する内容、質疑応答など）
  • メンターが指定したお題でPHPメンターズブログ記事執筆
    (1〜2ヶ月に1記事程度)

興味を持たれた方は、まずは以下のどれかでご連絡ください。

• email: contact@phpmentors.jp
• twitter: @phpmentors
• facebook: PHPメンターズのページ
• Tumblrのメッセージ

Symfony入門時に迷わないための指針

Symfonyでアプリケーションを開発する際、たとえばコンフィギュレーションの方法が複数ありますが、入門時にはどれを選択すればよいのか迷ってしまいます。迷いそうなポイントと、最初におすすめする選択肢を以下に挙げておきます。

• バンドルの分割：1つのバンドルで作る
• ルーティングのコンフィギュレーション：アノテーションを使う
• Doctrineのマッピング定義：アノテーションを使う
• フォームのバリデーション定義：アノテーションを使う
• Doctrineのクエリー：エンティティリポジトリ内で、簡単なクエリの場合はDoctrineのファインダー、やや複雑なものはQueryBuilderを用いる

このような判断のポイントも含む、入門〜初級者向けにアプリケーションの設計・実装方法を「型」として示している「PHPメンターズ流 設計と実装の型」も合わせて参照してください。

また、PHPメンターズの有償トレーニングコースでは、設計と実装の型をベースに基礎知識の解説を行い、実際に手を動かして作り方を学ぶ場となっています。

6月14日(金)、15日(土) PHPメンターズトレーニングセミナー「Symfony2によるWebアプリケーション開発入門 2日間コース」開催のご案内

この度PHPメンターズは、6月14日(金)と6月15日(土)に東京でPHPアプリケーションフレームワークSymfonyのトレーニングセミナー「Symfony2によるWebアプリケーション開発入門 2日間コース」を開催いたします。

Symfonyはプログラミング言語PHP向けのアプリケーション開発フレームワークであり、Fabien Potencier氏と多くの貢献者によって開発されています。5月末には最初の長期サポート（LTS）版となるバージョン2.3がリリースされる予定です。

私たちは、開発対象となる事業や技術の分野（ドメイン）に関する問題を解決することがソフトウェアの中心的な目標であり、アプリケーション開発者にとって最も重要なのは、ドメインの知識をドメインモデルとして体系化し、それをソフトウェアで表現することであると考えています。ドメインレイヤーの高い自由度、実績のある設計・実装手法との高い親和性といった特徴により、Symfonyはこのような考えの実践に最も適したフレームワークの一つとなっています。

本トレーニングセミナーは、基礎編・実践編の二部構成となっており、基礎編ではSymfonyでWebアプリケーション開発するにあたって必要な基礎知識を学び、実践編では進行に応じて基礎知識を学びつつ実際に手を動かしながらSymfonyでWebアプリケーションを作ります。Symfonyを使ったWebアプリケーションの設計・実装、フレームワークやプログラミング言語を超えたドメインモデルの設計・実装、それらをまとめ上げるのに必要なアーキテクチャーや原理原則等を学ぶための機会として是非ご活用ください。

お申し込みはこちらから

トレーニングサービス、開催実績について

作成するアプリケーションについて

• Info 本トレーニングセミナーおよび有償トレーニングサービスに関するお問い合わせはtraining@phpmentors.jpまでお願いいたします。

Symfony2によるWebアプリケーション開発入門 2日間コース 開催情報

コース概要

基礎編では良いソフトウェアを作るための考え方、ドメイン駆動設計の基礎、Symfonyの概要を学びます。実践編では講師陣の指導の下実際に手を動かしながら、ドメイン駆動設計を基盤にしたSymfonyによるWebアプリケーション開発を学びます。

• Info 使用するSymfonyのバージョンは2.2.1となります。
• Important 本コースの受講にはノートパソコンが必要です。受講の際はお手持ちのノートパソコンをご持参ください。ノートパソコンの貸し出しを希望される方はお申し込み時に該当するオプションを選択してください。

対象

• Webアプリケーション開発者
• Webアプリケーションフレームワークの導入を検討されている方
• Symfonyの導入を検討されている方
• Symfonyを基礎から学びたい方
• ドメイン駆動設計を実践したい方

前提となる知識・経験

PHPによるWebアプリケーション開発経験

修得目標

• 良いソフトウェアを作るための考え方
• Symfonyを使ったWebアプリケーション開発の基礎
• ドメイン駆動設計に基づいたアプリケーション開発の基礎

開催日時

Info 6月14日(金) 13:00 - 18:00、6月15日(土) 10:00 - 18:00

• ※昼休憩他適宜休憩を挟みます。
• ※2日目は昼食にお弁当をご用意させていただきます。

講師

久保 敦啓、後藤 秀宣

定員

Info 10名

最小開催人数

4名

Warning キャンセル期限に受講者数が各開催の定める最小開催人数に満たない場合、開催を中止することがあります。開催を中止する場合は遅くとも6月8日(土)までにその旨をご連絡し、受講料の全額を返金いたします。

受講料

Info 55,000円（ノートパソコンの貸し出しを希望される方は65,000円）

※受講料は税込みです。

お申し込み方法

Important トレーニングサービス利用規約にご同意いただいた上でお申し込みサイトからお申し込みください。

お申し込み期限

Info 6月6日(木) 17:30

キャンセル期限

Info 6月7日(金) 17:30

受講会場

Info 株式会社VOYAGE GROUP 150-0045 東京都渋谷区神泉町8-16 渋谷ファーストプレイス8F

主催

PHPメンターズ

コース内容

※受講当日の内容と一部異なる場合があります。

イントロダクション（30分）

1. Symfonyについての基礎知識
   1. Symfonyインストールと設定の概略
   2. ファイルとディレクトリ
   3. プロジェクトの初期構成

基礎編（30分）

1. 良いソフトウェア
   1. ソフトウェアの核心
   2. ドメイン
   3. ドメインモデル
   4. レイヤーアーキテクチャとドメインモデル
2. 巨人の肩の上に立つ
   1. 開発プロセス・方法論
   2. アーキテクチャーパターン・スタイル
   3. デザインパターン
   4. フレームワーク
   5. ライブラリ
3. ドメイン駆動設計
   1. 代表的なパターン
   2. ドメインモデルに関するパターン
4. Symfonyの概要
   1. Symfonyの特徴
   2. Symfonyの歴史

実践編（480分）

1. ドメインモデル（180分）
   1. ユースケース
   2. データモデル
   3. サービス、エンティティ、リポジトリ、ファクトリ
   4. オブジェクトの永続化（Doctrine2 ORM）
   5. ユニットテスト
2. ページフロー（120分）
   1. ルーティング
   2. コントローラ
   3. テンプレート（Twig）
3. フォーム（120分）
   1. フォームの定義
   2. バリデーション
4. DIコンテナ（60分）
   1. サービスの定義
   2. ファンクショナル（機能）テスト
   3. ユニットテストとDIコンテナ

まとめ（20分）

タイムテーブル

お申し込みはこちらから

WEB+DB PRESS PHP連載第6回「TYPO3 Flowでドメイン駆動設計入門」を執筆しました

技術評論社WEB+DB PRESSのPHP連載「巨人の肩からPHP - 先人たちに学ぶモダンプログラミング」の連載第6回「TYPO3 Flowでドメイン駆動設計入門」を収録したvol.74が発売されます。

• WEB+DB PRESS Vol.74｜gihyo.jp … 技術評論社

第6回では、ドメイン駆動設計を取り上げています。ドメイン駆動設計の基本概念と、実際にドメイン駆動設計のスタイルでソフトウェアを開発する時の要点から解説しています。また、ドメイン駆動設計でアプリケーションを開発することを全面的に謳ったフレームワークTYPO3 Flowを使って、DIの機能などを使いながらサンプリアプリケーションを実装していく流れも解説しています。

• TYPO3 Flow Enterprise PHP Framework

WEB+DB PRESS vol.74には、アリエル・ネットワーク株式会社井上誠一郎氏による特集「良い設計の基礎知識」も収録されています。依存とは何か、モジュールの安定／不安定と依存性の方向といった、巨人の肩からPHPの連載やPHPメンターズブログで扱っている事柄が、難しいと感じさせない文章で解説されています。PHP連載と合わせて、この特集記事もお読みになると、知識が補完されるかと思います。

DDDのリポジトリの外部依存とオブジェクト指向の原則の適用について

DDDのリポジトリがORMコンポーネントへ依存することの是非について、オブジェクト指向の原則の面から解説します。

リポジトリ（repository）とは、収納場所・倉庫・貯蔵庫を表す言葉です。

DDD（ドメイン駆動設計）では、リポジトリはモデル駆動設計でドメインをモデリングする際のビルディングブロックの1つになっています。ビルディングブロックとは基本構成要素のことで、ドメインをモデリングする際の基本部品として使います。

DDDのリポジトリの役目は、ドメインレイヤーのオブジェクトから永続化レイヤーを隠蔽することです。リポジトリ＝”エンティティの貯蔵庫”という抽象化されたオブジェクトを持ち込み、ドメインレイヤーの内部では貯蔵庫からエンティティを取り出すように設計・実装します。

構築するシステム（ここでは何か１つのシステムのみをイメージしてください）においてアーキテクチャが決定すると、その段階では永続化レイヤーに使われるコンポーネントが１つ選定されているでしょう。DDDのリポジトリは、ドメインレイヤーの中で永続化コンポーネントとのやり取りを担当します。根本的には、リポジトリは何らかの永続化コンポーネントに依存することになります。

依存関係逆転の原則

ドメインレイヤーはピュアに保つ。これがドメイン駆動設計における基本ポリシーです。しかし、外部とのやり取りを責務として持つオブジェクトについては、根本的に外部への依存を無くすことはできません。次の図のように、何らかのORMコンポーネントを利用した実装になるのは必然で、つまり依存が持ち込まれます。例えばSymfony Standard Editionの構成であれば、ORMコンポーネントにDoctrineが使われます。リポジトリは、Doctrineの提供するリポジトリ用の基底クラスであるEntityRepositoryを継承した実装になります。ドメインレイヤーの実装をドメインパッケージ、ORMはORMパッケージとしてまとめられていることを想定しています。

このように外部への依存を持ってしまった部分に対して、オブジェクト指向のクラス設計原則（SOLID原則）の1つである依存関係逆転の原則（DIP：Dependency Inversion Principle）を適用するとどうなるでしょうか。

依存関係逆転の原則では、直接依存しあう2つのクラスについて、間にインターフェイスを設け、2つのクラスそれぞれがインターフェイスに依存するように変更します。リポジトリの例では、ドメインパッケージには特定のリポジトリのインターフェイス（例：UserRepositoryInterface）のみを配置するようにします。リポジトリの実装は、ドメインパッケージの外に配置した実クラス（UserRepository）にて行います。このクラスが、ドメインパッケージにあるインターフェイスを実装し、ORMコンポーネントの基底クラスを継承します。こうすることで、リポジトリの実装をドメインパッケージの外に出すことはできました。

それでは、ドメインパッケージの外に出たリポジトリの実装は、どこに属するのでしょうか？

リポジトリの実装は、リポジトリパッケージに配置することにします。このパッケージはドメインパッケージから依存関係の理由で分割したというだけであり、依然としてドメインレイヤーに属するものだということに注意してください。リポジトリパッケージを切り離したドメインパッケージは、外部依存を持たなくなり、凝集度が高くなっています。

再利用・リリース等価の原則

しかし、ドメインレイヤーのオブジェクトは、それぞれ変更されていく可能性が高いものです。リポジトリの持つメソッドを追加したいということも出てくるでしょう。この場合、ドメインパッケージに属するリポジトリのインターフェイスと、リポジトリパッケージに属するリポジトリ実クラスの両方を修正しなくてはなりません。つまり、個別のリポジトリのインターフェイスというのは不安定（＝変更が発生しやすい）なものだったわけです。不安定なものを抽象化することは、無理やり安定させようとするため矛盾・ひずみを生みます。結局ドメインの問題についての変更要求でドメインパッケージとリポジトリパッケージの両方に変更を加え、両方を同時にリリースするようになるでしょう。したがって、再利用・リリース等価の原則（REP：Reuse-Release Equivalency Principle）と照らしあわせても、これらは１つのパッケージにある方が自然と言えます。

また、現実のプロジェクトでは、リポジトリの操作には特定の汎用知識（問い合わせ方法）が必要になるでしょう。この用語をリポジトリごと・プロジェクトごとに再定義するのは手間であり、また、多くの場合この問い合わせ言語はドメインの本質部分ではありません。ORMの提供する問い合わせ用メソッドを「問い合わせドメインの言語」として自ドメインに輸入してしまうのが現実的です。

Doctrineの提供するリポジトリ基底クラス（EntityRepository）のインターフェイスが安定しているということも前提になります。

まとめ

DDDのリポジトリとORMコンポーネントの関係に着目して依存について解説しました。依存の排除に固執しすぎると、本来注力すべき部分から外れてしまう場合があります。パッケージの安定度を見極め、それに合わせた抽象化にとどめておくことで、「変更しやすさ」を維持していくことが肝要です。

参考

パッケージの安定度・不安定度といった尺度については、Robert C. Martin著『アジャイルソフトウェア開発の奥義 第2版』20.5.1「安定性」、20.5.2「安定性の尺度（目安）」を参照してください。

• Robert C. Martin - Dependency Inversion Principle(PDF)
• (山口 大輔氏による翻訳)
• DIP：Dependency Inversion Principle - BEAR Blog
• PHP ソフトウェアメトリック - BEAR Blog
• PHPメンターズ流 設計と実装の型

時計オブジェクト（ドメインクロック）を導入してテスト容易性と意図性を高める

現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。

<?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）も同時に高めることができるのです。

Practical Symfony #19: SymfonyのProfilerを特定のアクションで無効にするには

Symfonyには強力なProfilerがあり、開発時にはとても役に立ちますが、Profilerが開発の邪魔をするケースもあります。例えば、Doctrine経由で件数の多いレコードを取得しようとすると、Profiler用のDataCollectorへの記録に大量にメモリを消費し、応答に時間がかかったりPHPのメモリ制限値を超えて実行できなくなったりします。

回避策として、そのような特殊な処理を実行するアクションで、プロファイラを無効にしてしまいます。Profilerはdevの時に組み込まれるサービスの1つとして機能しているので、サービスコンテナから該当するオブジェクトを取得することで、Profilerを操作できます。

<?php
// プロファイラを無効にしたい
// コントローラのアクションメソッド内
if ($this->has('profiler')) {
    /* @var $profiler \Symfony\Component\HttpKernel\Profiler\Profiler */
    $profiler = $this->get('profiler');
    $profiler->disable();
}

関連

• カスタムデータコレクタの作成方法 | Symfony2日本語ドキュメント