Download the PHP package matthiasnoback/symfony-dependency-injection-test without Composer

On this page you can find all versions of the php package matthiasnoback/symfony-dependency-injection-test. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package symfony-dependency-injection-test

SymfonyDependencyInjectionTest

By Matthias Noback and contributors

Build Status

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.

Installation

Using Composer:

Usage

Testing a container extension

To test your own container extension class MyExtension create a class and extend from Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractExtensionTestCase. Then implement the getContainerExtensions() method:

Basically you will be testing your extension's load method, which will look something like this:

So in the test case you should test that after loading the container, the parameter has been set correctly:

To test the effect of different configuration values, use the first argument of load():

To prevent duplication of required configuration values, you can provide some minimal configuration, by overriding the getMinimalConfiguration() method of the test case.

Testing a compiler pass

To test a compiler pass, create a test class and extend from Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractCompilerPassTestCase. Then implement the registerCompilerPass() method:

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.

Standard test for unobtrusiveness

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:

So you need to always add one or more guard clauses inside the process() method:

Use findDefinition() instead of getDefinition()

You may not know in advance if a service id stands for a service definition, or for an alias. So instead of hasDefinition() and getDefinition() you may consider using has() and findDefinition(). These methods recognize both aliases and definitions.

Test different configuration file formats

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:

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:

List of assertions

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.
assertContainerBuilderHasExactParameter($parameterName)
Assert that the ContainerBuilder for this test has a parameter.
assertContainerBuilderHasExactParameter($parameterName, $expectedParameterValue)
Assert that the ContainerBuilder for this test has a parameter and that its value is the given value, as well as its type matches given value type.
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.
assertContainerBuilderHasServiceDefinitionWithServiceLocatorArgument($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 a ServiceLocator with a reference-map equal to the given value.
assertContainerBuilderHasServiceDefinitionWithMethodCall($serviceId, $method, array $arguments = [], $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 = [])
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.
assertContainerBuilderHasServiceLocator($serviceId, $expectedServiceMap)
Assert that the ContainerBuilder for this test has a ServiceLocator service definition with the given id.

Available methods to set up container

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 a Definition object that can be modified if necessary.
setParameter($parameterId, $parameterValue)
Set a parameter.

Version Guidance

Version Released PHPUnit Status
4.x Mar 28, 2019 8.x and 9.x Latest
3.x Mar 5, 2018 7.x Bugfixes
2.x May 9, 2017 6.x Bugfixes
1.x Jul 4, 2016 4.x and 5.x EOL

All versions of symfony-dependency-injection-test with dependencies

PHP Build Version
Package Version
Requires php Version ^8.1
matthiasnoback/symfony-config-test Version ^5.0
symfony/dependency-injection Version ^5.4 || ^6.2 || ^7.0
symfony/config Version ^5.4 || ^6.2 || ^7.0
symfony/yaml Version ^5.4 || ^6.2 || ^7.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package matthiasnoback/symfony-dependency-injection-test contains the following files

Loading the files please wait ....