By Matthias Noback
This library contains several PHPUnit test case classes and many semantic assertions which you can use to functionally test your container extensions (or "bundle extensions") and compiler passes. It also provides the tools to functionally test your container extension (or "bundle") configuration by verifying processed values from different types of configuration files.
Besides verifying their correctness, this library will also help you to adopt a TDD approach when developing these classes.
Using Composer:
php composer.phar require --dev matthiasnoback/symfony-dependency-injection-test
To test your own container extension class MyExtension
create a class and extend from
Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractExtensionTestCase
. Then implement the
getContainerExtensions()
method:
<?php
use Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractExtensionTestCase;
class MyExtensionTest extends AbstractExtensionTestCase
{
protected function getContainerExtensions()
{
return array(
new MyExtension()
);
}
}
Basically you will be testing your extension's load method, which will look something like this:
<?php
class MyExtension extends Extension
{
public function load(array $config, ContainerBuilder $container)
{
$loader = new XmlFileLoader($container, new FileLocator(__DIR__));
$loader->load('services.xml');
// maybe process the configuration values in $config, then:
$container->setParameter('parameter_name', 'some value');
}
}
So in the test case you should test that after loading the container, the parameter has been set correctly:
<?php
class MyExtensionTest extends AbstractExtensionTestCase
{
/**
* @test
*/
public function after_loading_the_correct_parameter_has_been_set()
{
$this->load();
$this->assertContainerBuilderHasParameter('parameter_name', 'some value');
}
}
To test the effect of different configuration values, use the first argument of load()
:
<?php
class MyExtensionTest extends AbstractExtensionTestCase
{
/**
* @test
*/
public function after_loading_the_correct_parameter_has_been_set()
{
$this->load(array('my' => array('enabled' => 'false')));
...
}
}
To prevent duplication of required configuration values, you can provide some minimal configuration, by overriding
the getMinimalConfiguration()
method of the test case.
To test a compiler pass, create a test class and extend from
Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractCompilerPassTestCase
. Then implement the registerCompilerPass()
method:
<?php
use Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractCompilerPassTestCase;
class MyCompilerPassTest extends AbstractCompilerPassTestCase
{
protected function registerCompilerPass(ContainerBuilder $container)
{
$container->addCompilerPass(new MyCompilerPass());
}
}
In each test you can first set up the ContainerBuilder
instance properly, depending on what your compiler pass is
expected to do. For instance you can add some definitions with specific tags you will collect. Then after the "arrange"
phase of your test, you need to "act", by calling the compile()
method. Finally you may enter the "assert" stage and
you should verify the correct behavior of the compiler pass by making assertions about the ContainerBuilder
instance.
<?php
class MyCompilerPassTest extends AbstractCompilerPassTestCase
{
/**
* @test
*/
public function if_compiler_pass_collects_services_by_adding_method_calls_these_will_exist()
{
$collectingService = new Definition();
$this->setDefinition('collecting_service_id', $collectingService);
$collectedService = new Definition();
$collectedService->addTag('collect_with_method_calls');
$this->setDefinition('collected_service', $collectedService);
$this->compile();
$this->assertContainerBuilderHasServiceDefinitionWithMethodCall(
'collecting_service_id',
'add',
array(
new Reference('collected_service')
)
);
}
}
The AbstractCompilerPassTestCase
class always executes one specific test -
compilation_should_not_fail_with_empty_container()
- which makes sure that the compiler pass is unobtrusive. For
example, when your compiler pass assumes the existence of a service, an exception will be thrown, and this test will
fail:
<?php
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
class MyCompilerPass implements CompilerPassInterface
{
public function process(ContainerBuilder $container)
{
$definition = $container->getDefinition('some_service_id');
...
}
}
So you need to always add one or more guard clauses inside the process()
method:
<?php
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
class MyCompilerPass implements CompilerPassInterface
{
public function process(ContainerBuilder $container)
{
if (!$container->hasDefinition('some_service_id')) {
return;
}
$definition = $container->getDefinition('some_service_id');
...
}
}
You may not know in advance if a service id stands for a service definition, or for an alias. So instead of
hasDefinition()
andgetDefinition()
you may consider usinghas()
andfindDefinition()
. These methods recognize both aliases and definitions.
The Symfony DependencyInjection component supports many different types of configuration loaders: Yaml, XML, and
PHP files, but also closures. When you create a Configuration
class for your bundle, you need to make sure that each
of these formats is supported. Special attention needs to be given to XML files.
In order to verify that any type of configuration file will be correctly loaded by your bundle, you must install the
SymfonyConfigTest library and create a test class that extends
from AbstractExtensionConfigurationTestCase
:
<?php
use Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractExtensionConfigurationTestCase;
class ConfigurationTest extends AbstractExtensionConfigurationTestCase
{
protected function getContainerExtension()
{
return new TwigExtension();
}
protected function getConfiguration()
{
return new Configuration();
}
}
Now inside each test method you can use the assertProcessedConfigurationEquals($expectedConfiguration, $sources)
method to verify that after loading the given sources the processed configuration equals the expected array of values:
# in Fixtures/config.yml
twig:
extensions: ['twig.extension.foo']
<!-- in Fixtures/config.xml -->
<container>
<twig:config>
<twig:extension>twig.extension.bar</twig:extension>
</twig:config>
</container>
<?php
...
class ConfigurationTest extends AbstractExtensionConfigurationTestCase
{
...
/**
* @test
*/
public function it_converts_extension_elements_to_extensions()
{
$expectedConfiguration = array(
'extensions' => array('twig.extension.foo', 'twig.extension.bar')
);
$sources = array(
__DIR__ . '/Fixtures/config.yml',
__DIR__ . '/Fixtures/config.xml',
)
$this->assertProcessedConfigurationEquals($expectedConfiguration, $sources);
}
}
These are the available semantic assertions for each of the test cases shown above:
assertContainerBuilderHasService($serviceId)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id. assertContainerBuilderHasService($serviceId, $expectedClass)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id and class. assertContainerBuilderNotHasService($serviceId)
- Assert that the
ContainerBuilder
for this test does not have a service definition with the given id. assertContainerBuilderHasSyntheticService($serviceId)
- Assert that the
ContainerBuilder
for this test has a synthetic service with the given id. assertContainerBuilderHasAlias($aliasId)
- Assert that the
ContainerBuilder
for this test has an alias. assertContainerBuilderHasAlias($aliasId, $expectedServiceId)
- Assert that the
ContainerBuilder
for this test has an alias and that it is an alias for the given service id. assertContainerBuilderHasParameter($parameterName)
- Assert that the
ContainerBuilder
for this test has a parameter. assertContainerBuilderHasParameter($parameterName, $expectedParameterValue)
- Assert that the
ContainerBuilder
for this test has a parameter and that its value is the given value. assertContainerBuilderHasServiceDefinitionWithArgument($serviceId, $argumentIndex)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id, which has an argument at the given index. assertContainerBuilderHasServiceDefinitionWithArgument($serviceId, $argumentIndex, $expectedValue)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id, which has an argument at the given index, and its value is the given value. assertContainerBuilderHasServiceDefinitionWithMethodCall($serviceId, $method, array $arguments = array(), $index = null)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id, which has a method call to the given method with the given arguments. If index is provided, invocation index order of method call is asserted as well. assertContainerBuilderHasServiceDefinitionWithTag($serviceId, $tag, array $attributes = array())
- Assert that the
ContainerBuilder
for this test has a service definition with the given id, which has the given tag with the given arguments. assertContainerBuilderHasServiceDefinitionWithParent($serviceId, $parentServiceId)
- Assert that the
ContainerBuilder
for this test has a service definition with the given id which is a decorated service and it has the given parent service.
In all test cases shown above, you have access to some methods to set up the container:
setDefinition($serviceId, $definition)
- Set a definition. The second parameter is a
Definition
class registerService($serviceId, $class)
- A shortcut for
setDefinition
. It returns aDefinition
object that can be modified if necessary. setParameter($parameterId, $parameterValue)
- Set a parameter.