#stagehand.testrunner

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および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を使用する場合はプロジェクトのプロパティを以下のように設定します。

プロジェクトのプロパティを開き、MakeGoodを選択します。

テスティングフレームワークでPHPUnitを選択します。

テストフォルダーにsrcディレクトリを追加します。

プリロードスクリプトに前述のブートストラップファイルのパスを入力します。

ユニットテストの実行

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

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ユーザーガイドをご覧ください。

参考

Piece FrameworkのプロダクトのひとつStagehand_TestRunnerは、CLIでユニットテストを実行するための継続的テストランナーです。Stagehand_TestRunner v3の実装には多くのSymfonyコンポーネントが使われています。今回はStagehand_TestRunnerを動作させる上で重要な役割を果たしているDependency Injectionコンポーネントについて具体的な使い方を解説します。

Symfony Dependency Injectionコンポーネント

Dependency InjectionコンポーネントはSymfonyにおけるDIコンテナの実装であり、WebアプリケーションフレームワークとしてのSymfonyの基盤となるプロダクトです。サービスの依存性とその注入方法の定義、サービスの作成・取得、サービスへの依存性の注入、といったDIコンテナの基本機能に加えて、タグによる拡張ポイント・拡張の定義、Configコンポーネントとの統合、コンパイラによるカスタマイズ可能な最適化プロセス等の特徴を持ちます。

構成の知識とDIコンテナ

　可変性を持つアーキテクチャの設計では，必ずしも UML のこうした機能を使う必要はないが，何らかの設計上の意図を明確化する表現法を利用して，資産管理を考えることは重要である．

...

　このようにして可変性を分離できれば，可変部分をカプセル化し変更の影響を局所化し，あるいは，実行環境の外に定義して，可変点での選択肢を柔軟に取ることが可能となる．たとえば，オブジェクト指向におけるインターフェイスと実装の分離の原則を使った，ストラテジーパターンによる実装や，DI（Dependency Injection）による実行時の実装部分の選択がこの例である．

— 萩原正義 ユニシス技報 93号 Software Factories，現状と未来 － マイクロソフト社の次世代開発基盤技術（PDF）

DIコンテナを使用するメリットとしては、依存性の反転によるコンポーネントの疎結合化の促進、テスタビリティの向上等がよく知られています。しかし、PHPのような動的な言語では静的な言語と比べてこのようなメリットが少ないため、これまで何度となく不要論が唱えられてきました。

しかし、ソフトウェアを構成するための実装コンポーネントの組み合わせに関する知識（構成の知識）を記述する言語としてDIコンテナを位置付けるとどうでしょうか。可変性を含む構成の知識を資産と捉え、サービスの定義（とその可変部分によって構成されたDSL）によって設計上の意図を明確化し、コンパイル時や実行時に可変部分を選択しながらソフトウェアを構成する、そのためのエンジンとしてDIコンテナを使うのです。

このようにDIコンテナを使うことは、実装にともなうソフトウェアの設計情報の喪失をより少なくする手段として多くの言語で有用ではないかと私は考えています。

Stagehand_TestRunnerではまさにそのような意図をもってDependency Injectionコンポーネントを使用しています。

Dependency Injectionコンポーネントを単体で使用する

では具体的な使い方をみていきます。まずは全体像を知るためにDependency Injectionコンポーネントの構造をみてみましょう。以下の図はDependency Injectionコンポーネントを使うにあたって登場するクラスの関連を表したものです。

赤はDependency Injectionコンポーネントが提供するクラスおよびインターフェイスで、緑はユーザーのDependency Injectionコンポーネント関連クラス、青はユーザーのDIコンテナ管理対象クラスを表しています。最終的にFooサービスに依存するクライアントは、DIコンテナによる依存性の注入によって暗黙的に、あるいはファクトリーを使って明示的にFooサービスを取得することになります。

DIコンテナのコンパイル

ContainerBuilderはその名前の通りアプリケーション固有のDIコンテナを組み立てるためのクラスであり、compile()メソッドによって自身が保持するサービス定義とパラメーターをコンパイルします。コンパイルの実態はDIコンテナの最適化です。

PhpDumperクラスはコンパイル済みのContainerBuilderオブジェクトをContainerを継承したクラスのソースコードに変換します。Symfonyアプリケーションでは起動直後に実行されるブートストラップファイルapp/booststrap.php.cacheにこのコンパイルプロセスが組み込まれているため開発者が意識する必要はありませんが、単体で使う場合はコンパイルプロセスを自前で準備する必要があります。Stagehand_TestRunnerにおけるコンパイルプロセスはtestrunner compileコマンドに組み込まれています。このコマンドによって実行されることになるメソッドから順にみていきましょう。

Stagehand\TestRunner\CLI\TestRunnerApplication\Command\CompileCommand:

<?php ... namespace Stagehand\TestRunner\CLI\TestRunnerApplication\Command; ... use Stagehand\TestRunner\DependencyInjection\Compiler; ... class CompileCommand extends Command { ... protected function execute(InputInterface $input, OutputInterface $output) { $compiler = new Compiler(); $compiler->compile(); return 0; } ...

Compilerはコンパイルプロセスを実装したStagehand_TestRunnerのクラスです。Compiler::compile()はコンパイルプロセスそのものを表現するメソッドです。

Stagehand\TestRunner\DependencyInjection\Compiler:

<?php ... namespace Stagehand\TestRunner\DependencyInjection; ... class Compiler { ... public function compile() { // (1) ContainerBuilderオブジェクトの作成 $containerBuilder = new UnfreezableContainerBuilder(); // (2) エクステンションの登録 foreach (ExtensionRepository::findAll() as $extension) { $containerBuilder->registerExtension($extension); } // (3) エクステンションの設定のロード foreach ($containerBuilder->getExtensions() as $extension) { /* @var $extension \Symfony\Component\DependencyInjection\Extension\ExtensionInterface */ $containerBuilder->loadFromExtension($extension->getAlias(), array()); } // (4) 最適化戦略のカスタマイズ $containerBuilder->getCompilerPassConfig()->setOptimizationPasses( array_filter( $containerBuilder->getCompilerPassConfig()->getOptimizationPasses(), function (CompilerPassInterface $compilerPass) { return !($compilerPass instanceof ResolveParameterPlaceHoldersPass); } )); // (5) コンパイルとダンプ $compiler = new \Stagehand\ComponentFactory\Compiler( $containerBuilder, self::COMPILED_CONTAINER_CLASS, self::COMPILED_CONTAINER_NAMESPACE ); file_put_contents( __DIR__ . '/' . self::COMPILED_CONTAINER_CLASS . '.php', $compiler->compile() ); } ...

このプロセスで重要なのは、ContainerBuilderオブジェクトに対する3つの操作、すなわちエクステンションの登録(2)とその設定のロード(3)、コンパイルとダンプ(5)です。

(3)で空の配列を渡していますが、これはStagehand_TestRunnerの設計に起因するのものです。通常は設定ファイル等から読み込んだ生の設定を渡すことになるでしょう。

(2)で登録したエクステンションは(5)でContainerBuilder::compile()メソッドを経由して呼び出されます。

Stagehand\ComponentFactory\Compiler:

<?php ... namespace Stagehand\ComponentFactory; ... class Compiler { ... public function compile($evaluatable = false) { $this->containerBuilder->compile(); $phpDumper = new PhpDumper($this->containerBuilder); $containerClassSource = $phpDumper->dump(array('class' => $this->class)); if (!is_null($this->namespace)) { $containerClassSource = preg_replace( '/^<\?php/', '<?php' . PHP_EOL . 'namespace ' . $this->namespace . ';' . PHP_EOL, $containerClassSource ); } if ($evaluatable) { $containerClassSource = preg_replace('/^<\?php/', '', $containerClassSource); } return $containerClassSource; } ...

Stagehand_TestRunnerのエクステンションは解説に不向きなため、ここでは別のプロダクトPiece_Questetraのエクステンションをみてみましょう。

Piece\Questetra\DependencyInjection\PieceQuestetraExtension:

<?php ... namespace Piece\Questetra\DependencyInjection; ... use Symfony\Component\HttpKernel\DependencyInjection\Extension; ... class PieceQuestetraExtension extends Extension { public function load(array $configs, ContainerBuilder $container) { $config = $this->processConfiguration(new Configuration(), $configs); $loader = new YamlFileLoader($container, new FileLocator(__DIR__ . '/../Resources/config')); $loader->load('services.yml'); $container->setParameter('piece_questetra.context_root', $config['context_root']); $container->setParameter('piece_questetra.user_id', $config['authentication']['user_id']); $container->setParameter('piece_questetra.password', $config['authentication']['password']); } ...

エクステンションのload()メソッドではエクステンションのサービス定義をロードし、受け取った設定をサービス定義やパラメーター等に変換します。

ソフトウェアの可変性の観点からみれば、ここは構成の知識の固定部分（サービス定義）と可変部分（設定）がパラメーターを介して結合し、実装コンポーネントの構成が行われる場所と考えることができます。

最適化戦略のカスタマイズ

DIコンテナの最適化戦略はContainerBuilder::getCompilerPassConfig()メソッドで返されるPassConfigオブジェクトで表現されています。戦略の一つ一つはコンパイラパスと呼ばれるCompilerPassInterfaceインターフェイスのインスタンスです。それらはContainerBuilder::compile()メソッドの呼び出しによって実行され、DIコンテナに適用されます。ユーザーは自由にコンパイラパスの追加・削除・変更を行うことができます。

Stagehand_TestRunnerでは独自のContainerBuilderオブジェクトを使い(1)、パラメーターをインライン化するResolveParameterPlaceHoldersPassオブジェクトを最適化パスから削除することで(4)、コマンドラインパラメーターをDIコンテナのパラメーターに変換できる余地を作っています。

DIコンテナの使用

コンパイルが終われば、アプリケーション固有のDIコンテナをインスタンス化して使うことができます。Stagehand_TestRunnerの場合、PluginCommand::execute()メソッドでDIコンテナのインスタンス化とtest_runnerサービスの作成を行っています。

Stagehand\TestRunner\CLI\TestRunnerApplication\Command\PluginCommand:

<?php ... namespace Stagehand\TestRunner\CLI\TestRunnerApplication\Command; ... abstract class PluginCommand extends Command { ... protected function execute(InputInterface $input, OutputInterface $output) { if (!class_exists(Compiler::COMPILED_CONTAINER_NAMESPACE . '\\' . Compiler::COMPILED_CONTAINER_CLASS)) { $output->writeln( 'Please run the following command before running the ' . $this->getName() . ' command:' . PHP_EOL . PHP_EOL . ' testrunner compile' ); return 1; } // アプリケーション固有のDIコンテナの作成 $container = $this->createContainer(); ApplicationContext::getInstance()->getComponentFactory()->setContainer($container); ApplicationContext::getInstance()->setPlugin($this->getPlugin()); ApplicationContext::getInstance()->setComponent('input', $input); ApplicationContext::getInstance()->setComponent('output', $output); $transformation = $this->createTransformation($container); $this->transformToConfiguration($input, $output, $transformation); $transformation->transformToContainerParameters(); // test_runnerサービスの作成とrun()メソッドの実行 $this->createTestRunner()->run(); return 0; } ... protected function createContainer() { return new Container(); } ... protected function createTestRunner() { return ApplicationContext::getInstance()->createComponent('test_runner'); } ...

Stagehand_TestRunnerのプロダクションコードでサービス名を埋めこんでいるのはこの一箇所だけです。サービス名をどのようにコードの外に追いやっているのか、興味のある方は以下のクラスやサービス定義ファイルを覗いてみてください。

Stagehand\TestRunner\Core\ApplicationContext

Stagehand\TestRunner\Core\Plugin\PluginAwareFactory

Stagehand\ComponentFactory\ComponentAwareFactory

Stagehand\ComponentFactory\ComponentFactory

src/Stagehand/TestRunner/Resources/config/general.yml

おわりに

これまでみてきたようにDependency Injectionコンポーネントは単独で使うには少々手間がかかります。また、依存性とその注入方法の定義が一体となっているため、JSR-330相当の機能を持つDIコンテナ（例えばRay.DiやDingが挙げられます。）と比べると関心の分離という点で遅れをとっているのは確かです。

しかし、Dependency Injectionコンポーネントには、Symfonyアプリケーションとの親和性の高さは当然のことながら、タグによる拡張ポイント・拡張の定義、Configコンポーネントとの統合、コンパイラによるカスタマイズ可能な最適化プロセス等、他にはない特徴があります。これらはジェネレーティブプログラミングの世界を標榜する私にとって大きな魅力となっています。

参考

Dependency Injection (current) - Symfony

CLI のための継続的テストランナー v3 - Stagehand_TestRunner - Piece Framework

Software Factories，現状と未来 － マイクロソフト社の次世代開発基盤技術（PDF）

Piece FrameworkのプロダクトのひとつStagehand_TestRunnerは、CLIでユニットテストを実行するための継続的テストランナーです。Stagehand_TestRunner v3の実装には多くのSymfonyコンポーネントが使われています。コンポーネントはソフトウェアにおける部品を指す用語です。SymfonyコンポーネントはPEARパッケージと同様単体で使えるライブラリパッケージであり、多くのものは簡単に導入することができます。

Symfony Finderコンポーネント

Finderコンポーネントはファイルとディレクトリを検索するためのパッケージであり、簡潔かつ強力な検索式や、流れるようなインターフェース(Fluent Interface) によるDSLを使った検索式の組み立てなどが特徴です。Stagehand_TestRunnerではテストファイルの収集や、ディレクトリの監視などの実装に使われています。

テストファイルの収集はStagehand_TestRunnerの重要な機能のひとつであり、中核となるプロセスは抽象クラスStagehand\TestRunner\Collector\Collectorのcollectメソッドに記述されています。

Stagehand\TestRunner\Collector\Collector:

<?php ... namespace Stagehand\TestRunner\Collector; use Symfony\Component\Finder\Finder; ... abstract class Collector { ... public function collect() { $self = $this; $fileSystem = new FileSystem(); $environment = $this->environment; $this->testTargetRepository->walkOnResources(function ($resource, $index, TestTargetRepository $testTargetRepository) use ($self, $fileSystem, $environment) { $absoluteTargetPath = $fileSystem->getAbsolutePath($resource, $environment->getWorkingDirectoryAtStartup()); if (!file_exists($absoluteTargetPath)) { throw new \UnexpectedValueException(sprintf('The directory or file [ %s ] is not found', $absoluteTargetPath)); } if (is_dir($absoluteTargetPath)) { $files = Finder::create() ->files() ->in($absoluteTargetPath) ->depth($self->isRecursive() ? '>= 0' : '== 0') ->sortByName(); foreach ($files as $file) { call_user_func(array($self, 'collectTestCasesFromFile'), $file->getPathname()); } } else { call_user_func(array($self, 'collectTestCasesFromFile'), $absoluteTargetPath); } }); return $this->suite; } ...

テストファイルの収集において、Finderコンポーネントは以下のような条件に合致するファイルを検索するために使われています。

ファイルであること

指定されたディレクトリの絶対パス以下を検索対象とすること

指定されたディレクトリ以下のすべてのディレクトリ、または指定されたディレクトリのみを検索対象とすること

$files = Finder::create() ->files() // (1) ->in($absoluteTargetPath) // (2) ->depth($self->isRecursive() ? '>= 0' : '== 0') // (3) ->sortByName(); // 見つかった要素を名前順にソートする

検索式DSLは検索式を表現するメソッドが常に$thisオブジェクトを返すことで実現されています。

さて、検索式が確定したら次は検索の実行です。検索の実行はFinder::getIterator()メソッドで行われます。FinderクラスはIteratorAggregateインターフェイスを実装していますので、foreachの配列式としてFinderオブジェクトを与えるとgetIterator()メソッドが呼び出されます。

foreach ($files as $file) { call_user_func(array($self, 'collectTestCasesFromFile'), $file->getPathname()); }

Finderコンポーネントにはここに挙げた機能に加えて、更新日時やファイルサイズ、カスタムフィルタによるフィルタリング機能もあります。Finderコンポーネントはファイルやディレクトリを検索する場合に大いに役立つパッケージです。ユーザーが直接操作するクラスはFinderひとつだけなので導入も非常に簡単です。

参考

The Finder Component (current) - Symfony

CLI のための継続的テストランナー v3 - Stagehand_TestRunner - Piece Framework

昨日Piece ProjectからStagehand_TestRunner 3.0.0(以後Stagehand_TestRunner v3)をリリースいたしました。バージョン2.0.0のリリースからおよそ4年3ヶ月ぶりというメジャーアップデートとなった今回のリリースでは一体今までと何が変わったのか、リリースノートを補足する形でご紹介したいと思います。

Stagehand_TestRunnerとは？

Stagehand_TestRunner は CLI でユニットテストを実行するための継続的テストランナーです。

Stagehand_TestRunner はローカル環境におけるユニットテストをとても簡単で快適なものにします。加えて Jenkins のような継続的インテグレーションサーバと簡単に統合することもできます。統合開発環境 (IDE) との統合を考慮して設計されているため、開発者が MakeGood のような拡張を作成することもできます。

Stagehand_TestRunnerはCLIのテストランナーを提供するコマンドラインアプリケーションです。PHPUnitを始めさまざまなテスティングフレームワークをサポートしており、同一のコマンドラインインターフェイスを使ってテストを簡単に実行することができます。手動による実行に加えて、特定のディレクトリ以下のファイルの変更を監視し何らかの変更があれば自動的にテストを実行する機能（Autotest）があります。

また、JUnit XMLフォーマットによるログ出力をサポートしており（この機能はすべてのテスティングフレームワークで使うことができます！）、継続的インテグレーションサーバと簡単に統合することができます。

加えて統合開発環境（IDE）上のテストランナー拡張を作成する際のバックエンドとしてお使いいただくこともできます。具体例としてはEclipseプラグインのMakeGoodがあります。

Stagehand_TestRunner v3の新機能

PHP 5.3への移行

PHP 5.3.0がリリースされたのは2009年6月30日、今から3年近く前のことです。当時のStagehand_TestRunnerのバージョンは2.6.2であり、その後今回のバージョンに至るまで実に22回に及ぶリリースを行ってきました。今年の3月1日にはPHP 5.4.0がリリースされており、このタイミングのリリースであれば5.4.0以降のみのサポートとすることも検討していましたが、Stagehand_TestRunner v3で多くの力を借りているSymfonyがサポートするバージョン5.3.2以降に合わせることにしました。

新しいコマンドラインアプリケーション

コマンドラインアプリケーションはSymfony Consoleコンポーネントをベースとするものになりました。これによってStagehand_TestRunner v3はより良いルック・アンド・フィールと規律のあるコマンド体系を提供します。

Stagehand_TestRunner v3のコマンドラインアプリケーションは名前空間Stagehand\TestRunner\CLI\TestRunnerApplicationで実装されています。

強化されたPHPSpecサポート

Stagehand_TestRunner v3ではPHPSpecの最新バージョンである1.3.0betaをサポートしました。加えて大幅な機能強化により、PHPUnitサポートと同等レベルの機能を提供します。これに関連し、MakeGoodの次期メジャーバージョンではPHPSpecをサポートする予定です。

SimpleTest 1.1のサポート

Stagehand_TestRunner v3ではSimpleTestの最新安定バージョン1.1.0をサポートしました。SimpleTestは今後積極的に開発が行われる見通しはありませんが、PHP 5対応バージョンの需要はある程度見込まれることから、Stagehand_TestRunner v3でも継続してサポートすることになりました。

YAMLベースの構成

YAMLで書かれた構成ファイルを使ってStagehand_TestRunnerの実行環境を構成できるようになりました。

general: framework: phpunit test_targets: recursive: autotest: watch_dirs: - src notify:

ユーザーから見えるStagehand_TestRunner v3の可変部分はSymfony ConfigコンポーネントとSymfony Dependency Injectionコンポーネントを使って構築されています。Symfony Configコンポーネントは、グラマー言語による文法定義を核とするDSL構築フレームワークともいえるものです。抽象として定義されたDSL文法は、特定の編集形式と無関係であり、いつでも任意の編集形式を採用することができます。またDSL実装系に必須であるレキサとパーサも開発者が実装する必要はありません。Stagehand_TestRunner v3ではSymfony Configコンポーネントの特性を活かし、YAMLによる構成とコマンドラインオプションが同一の仕組みの上に構築されています。このあたりは名前空間Stagehand\TestRunner\Core\Configurationで実装されています。また、名前空間Stagehand\TestRunner\Core\Transformationを見るとDSLによる構成がどのように実装コンポーネントに変換されているかがわかります。

パフォーマンスの向上

Stagehand_TestRunner v3ではアーキテクチャの改善にともない、テストの実行速度が大幅に向上しました。ランチャースクリプトの起動速度はわずかに遅くなりましたが、テストの実行速度は以前よりも速くなりました。

参考値として手元の環境ではStagehand_TestRunner v3自体の274のテストが2秒以下で完了します。v2の場合213のテストが2.5秒程度かかっていました。

おわりに

Stagehand_TestRunner v3はv2までの主要な特徴を継承しつつ、大きく改善されたアーキテクチャによって高い拡張性を提供します。実装には多くのSymfonyコンポーネントが使われており、その具体的な使用例としても参考にしていただけると思います。Stagehand_TestRunner v3のアーキテクチャ、設計、実装については今後のブログ記事で詳細に解説していきます。

参考

Stagehand_TestRunner 3.0.0 (stable) リリースノート