symfonytest / symfonydependencyinjectiontest Goto Github PK

Hi @matthiasnoback,

If it is not already possible, this bundle should be capable to invoke the Symfony\Component\DependencyInjection\Extension\PrependExtensionInterface::prepend() method in order to unit test it as well as the load method...

Do you agree?

Thank you!

ContainerBuilderHasServiceDefinitionConstraint::toString() threads expectedClass as a string value while an its object.

evaluateClass uses \PHPUnit_Util_Type::export() but I'm not sure this should also be used for toString().

See SymfonyTest/SymfonyConfigTest#3

See dustin10/VichUploaderBundle#746 for use case. I need load TwigExtension with his own config.

But I cann't just add new TwigExtenstion() to getContainerExtensions method. Can we make it more user-friendly? Allow pass to load method array with keys like twig => [/* twig config */], vichuploader => [/* vichuploader config */]?

using matthiasnoback/symfony-dependency-injection-test v3.1.0

PHP Fatal error:  Declaration of Matthias\SymfonyDependencyInjectionTest\PhpUnit\AbstractContainerBuilderTestCase::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in [...]/vendor/matthiasnoback/symfony-dependency-injection-test/PhpUnit/AbstractContainerBuilderTestCase.php on line 221

Due to a lack of a Resolver, its impossible to test configurations that import other types of configs, for example a yml file with:

imports:                            
    - { resource: constants.xml }   

Any ideas on how to achieve this?

Would be great to take care of this:

Symfony\Component\DependencyInjection\Definition::setFactoryMethod method is deprecated since version 2.6 and will be removed in 3.0. Use Definition::setFactory() instead

Thanks again for your library!

In the class LoaderFactory are conditions which checks the config file extension. Would be great if yaml would be supported

See #70. Since we can't enforce a specific PHPUnit version using standard Composer techniques (e.g. in the require section), we need to warn the users about incompatible usage in another way.

The test fails, because ContainerBuilder::getAlias() does not lower the given string anymore since 3.3.

If you bump requirement for phpunit to ^5.7|^6.0, you can use PHPUnit\Framework\TestCase instead of PHPUnit_Framework_TestCase (in 5.7 there is a forward-compatible layer).
Of course, this means dropping support for phpunit 4 (that is out of support, by the way)

Currently there is no way to assert that the container has a definition the parent of which is x.

When testing multiple configuration formats, the assertion is not executed seperetly for each source. Instead of that, all sources are parsed and after that the assertion is executed.

This will work for most of the configuration things, as they almost always have an unique key. When merging those arrays, nothing changes:

$one = array('foo' => 'cat');
$two = array('foo' => 'cat');

var_dump(array_merge($one, $two)); //> Array( [foo] => 'cat' )

But if you use a prototype without key, for instance:

$root
    ->fixXmlConfig('locale')
    ->children()
        ->arrayNode('locales')
            ->prototype('scalar')->end()
        ->end() // locales
    ->end();

Now, when using multiple sources, you get a numeric key. When merging these arrays, the items will be appended instead of replaced:

$one = array('cat');
$two = array('cat');

var_dump(array_merge($one, $two)); //> Array( [0] => 'cat', [1] => 'cat' )

This causes the test to fail.

If i just want to check, if the ContainerBuilder has a service, but i dont want/need to check against the concrete value, it would be great to change some the signatures like this:

assertContainerBuilderHasService($serviceId, $expectedClass=null)
assertContainerBuilderHasAlias($aliasId, $expectedServiceId=null)
assertContainerBuilderHasParameter($parameterName, $expectedParameterValue=null)
assertContainerBuilderHasServiceDefinitionWithArgument($serviceId, $argumentIndex, $expectedValue=null)

For me it was a little bit confusing at first, because the "has" inside the name did not get me to the "equals" check that will be made.

I made a P.R. with a modification to the extension so that it uses the prepend() method of the extension to test the presence of a related configuration node for another bundle (SonataAdminBundle). Is it possible to test that with your library ?

Considering that there is a service of type of "Registry", which gets injected with services of types of "Handler" via method call "addHendler" -> if order of injection of each individual handler via method call is significant, we are not able to test it.

Proposal: extend method signature of assertContainerBuilderHasServiceDefinitionWithMethodCall() to:

protected function assertContainerBuilderHasServiceDefinitionWithMethodCall(
    $serviceId,
    $method,
    array $arguments = array(),
    $index = null // Zero-based order of invocation of method call
)

This implementation will be BC compatible, if $index is provided, assert should check if method call has appropriate order in collection of registered method calls.

Application is useful, of course, when testing implementation of chain of responsibility pattern and/or visitor pattern where order of injection is prioritized.

I am willing to submit a patch, if you agree that this is a valid request for improvement.

I am getting a lot of warnings when installing/updating the package, saying something like: Class (name) does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0.

Example of affected classes:

• Matthias\SymfonyDependencyInjectionTest\Tests\PhpUnit\DependencyInjection\DefinitionHasTagConstraintTest
• Matthias\SymfonyConfigTest\Tests\PartialConfigurationIntegrationTest

As you can see it also affects your other SymfonyConfigTest package.

I just started reading the laravel 5.6 docs and php is not my forte I am still learning so try to use a lot of sample projects to learn but I cant seem to get the server up found a solution but unfortunately works on
an older version of php ^5.5.0 they said to use composer install and composer update but fix doesnt work for php 7 am using 7.2.6

See #4: it may sometimes be unclear which arguments are expected/valid when using the custom constraint classes/assertions. At least they should be validated.

I would expect the $container->getExtensionConfig() to return what I have defined in AbstractExtensionTestCase::getMinimalConfiguration(), but it returns an empty array.

There are currently some issues regarding compatibility with PHPUnit 5 which is quite important as PHPUnit 4 is not fully compatible with PHP 7.

@matthiasnoback Just to keep track of this issue. :)

Matthias\SymfonyServiceDefinitionValidator\Exception\InvalidServiceDefinitionsException]
Service definition validation errors (2):

• form.type_guesser.validator: Argument for type-hint "Symfony\Component\Validator\MetadataFactor
  yInterface" points to a service of class "Symfony\Component\Validator\ValidatorInterface"
• validator: Class "Symfony\Component\Validator\ValidatorBuilderInterface" does not exist

Hi,

So a while back I ran into a problem being that the extension that I was testing created a container instance that couldn't be dumped (but passed all tests).

To fix this I added the following assert to my TestCase:

use Symfony\Component\DependencyInjection\Dumper;

class TestCase {
....
    /**
     * Assert that the current container can be dumped.
     */
    private function assertContainerCanBeDumped()
    {
        $dumperCalls = array(
            Dumper\XmlDumper::class,
            Dumper\PhpDumper::class,
            Dumper\GraphvizDumper::class,
            Dumper\YamlDumper::class,
        );
        foreach ($dumperCalls as $dumperClass) {
            /** @var Dumper\Dumper $dumper */
            $dumper = new $dumperClass($this->container);
            $this->assertInstanceOf(Dumper\Dumper::class, $dumper);
            $dumper->dump();
        }
    }
....
}

Would this be worth creating a PR?

In some situations the PHPStorm test runner (and probably others as well) will run ContainerBuilderTestCase as a regulare test class and show a warning that it contains no tests. It should of course be marked as abstract.

I need to test that a certain service is not there but there is no assertContainerBuilderHasNotService ...

my tests are failing, I am wondering, why I can install version >=2.0, if i have PHPUnit 5.7.15 installed:

oskar.stark:/Volumes/development/workspaces/dashy (show-navi)$ composer show | grep phpunit/phpunit
phpunit/phpunit                                  5.7.15  The PHP Unit Testing framework.

oskar.stark:/Volumes/development/workspaces/dashy (show-navi)$ composer show | grep matthias
matthiasnoback/symfony-config-test               v3.0.1  Library for testing user classes related to the Symfony Config Component
matthiasnoback/symfony-dependency-injection-test v2.0.0  Library for testing user classes related to the Symfony Dependency Injection Component

IMO >=2.0 should have PHPUnit <=6.0 in the conflict section

I am trying to integrate your package under SonataAdminBundle: sonata-project/SonataAdminBundle#3932

Our SonataAdminExtension currently need the kernel.bundles parameter: https://github.com/sonata-project/SonataAdminBundle/blob/3.2.0/DependencyInjection/SonataAdminExtension.php#L37

But we got this error:

1) Sonata\AdminBundle\Tests\SonataAdminExtensionTest::testLoad
Symfony\Component\DependencyInjection\Exception\ParameterNotFoundException: You have requested a non-existent parameter "kernel.bundles".

/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/vendor/symfony/dependency-injection/ParameterBag/ParameterBag.php:84
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/vendor/symfony/dependency-injection/Container.php:127
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/DependencyInjection/SonataAdminExtension.php:220
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/vendor/symfony/dependency-injection/Compiler/MergeExtensionConfigurationPass.php:36
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/vendor/symfony/dependency-injection/Compiler/Compiler.php:104
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:545
/home/sullivan/projects/fork/sonata-project/SonataAdminBundle/Tests/DependencyInjection/SonataAdminExtensionTest.php:24

What is the best way to get/simulate this parameter this your package? Can this be possible?

Hi and thanks for this library, this gave me lot of time to make tests.

In your documentation, it's explain how to test Extenstion and CompilerPass, but what about the Bundle class itself?

For example, I would like to test the build method of this Bundle class:
https://github.com/Soullivaneuh/SLLHIsoCodesValidatorBundle/blob/master/src/SLLHIsoCodesValidatorBundle.php

Is that possible with your library? How?

Thanks.

Hey @matthiasnoback & other GitHubbers,
writing some tests last night I was thinking about testing dependency injection extensions and all the assertContainerBuilderHasService, assertContainerBuilderHasParameter etc assertations only make sense if they were actually added by the extension and not loaded via a yml/xml file. If my load method only loads a yml/xml file the only assertation that makes sense to me is that I check if that file was added as a file resource (and therefore loaded). So I was wondering if you think it makes sense to add a assertContainerBuilderHasResource assertion? For example
$this->assertContainerBuilderHasResource('src/AppBundle/Resources/config/services.xml');

...
There was 1 failure:

1) Symfony\Cmf\Bundle\RoutingBundle\Tests\Unit\DependencyInjection\CmfRoutingExtensionTest::testRouteBasepathsMerging with data set #2 (null, array('/cms/test'), array('/cms/routes', '/cms/test'), '/cms/routes')
The value of parameter "cmf_routing.dynamic.persistence.phpcr.route_basepaths" (Array &0 (
    0 => '/cms/routes'
    1 => '/cms/test'
)) does not match the expected value (Array &0 (
    0 => '/cms/test'
))
Failed asserting that Symfony\Component\DependencyInjection\ContainerBuilder Object &000000004ae804bd0000000034c3290d (
    ...
    'parameterBag' => Symfony\Component\DependencyInjection\ParameterBag\ParameterBag Object &000000004ae8069d0000000034
c3290d (
        'parameters' => Array &5 (
            ...
            'cmf_routing.dynamic.persistence.phpcr.route_basepaths' => Array &11 (
                0 => '/cms/test'
            )
            ...
    )
    ...
) has a parameter "cmf_routing.dynamic.persistence.phpcr.route_basepaths" with the given value.

As you can see, the actual value of the parameter is array('/cms/test'), while the expected was array('/cms/routes', '/cms/test'). The failure message says the opposite.

We should drop support for Symfony < 2.7 cause those versions are not maintained anymore.

This is a feature request. Thank you for this library which is very useful!

Would it be possible to add a method that asserts that a service id does not have a certain method call?

We have two warnings when testing on Symfony 4. See https://travis-ci.org/SymfonyTest/SymfonyDependencyInjectionTest/builds/309396321

Why is that?

When a definition is set up with the class using a service parameter, the parameter is not resolved.

This can be fixed by using $container->getParameterBag()->resolveValue($class).

Or is this intended?

Btw, I remember creating this issue in the past, but I can't find it. If I'm creating a duplicate one, I'm really sorry.

The 3 lines changed here https://github.com/SymfonyTest/SymfonyDependencyInjectionTest/pull/87/files#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780R18 are not changed BC.

It should be ^2.7 || ^3.0 || ^4.0.

This is why I have problems now upgrading a library that need to support sf4.0 and sf3.2.

Can I make a PR to fix this issue?

When the DefinitionHasArgumentConstraint is used to validate the existence and correctness of a definition argument, this does not work well with a service definition which is an instance of DefinitionDecorator. Instead of directly accessing the argument array, the constraint should try to call getArgument() on it, otherwise it will always fail.

When writing tests for a legacy application, I discovered that the checks performed in the ContainerBuilderHasAliasConstraint are not case-insensitive.

For example, take the following service definition and alias:

services:
   fooBar:
     class: \Foobar
   foo:
     alias: fooBar

Notice the capitalised B in the service id for the fooBar service definition. However, when using the assertContainerBuilderHasAlias(), you will have to lowercase the service id. The reason is that the Symfony DependencyInjection component lowercases all service ids and aliases.

I suggest to reflect this behaviour in the ContainerBuilderHasAliasConstraint and would be happy to open a pull request for this. Though I first wanted to ask for your opinion on this.

@matthiasnoback What do you think?

Because of the restriction to 0.* of the config tester, this cannot be installed along side of it when using ~1.0 for the config package.

I could not find such a assertion:

assertContainerBuilderHasServiceWithTag($serviceId, $tagName, $tagAttributes = array())

Would that be usefull?

Since this package itself will be installed as a --dev dependency I think it makes sense to require phpunit in the main require list, ensuring it's usable when installed.

I'll happily PR this when/if agreed to this proposal.

because it is throwing an error, that method is gone in 4.0 but no documentation about what is the new way was found by me 👶

PHPUnit\Framework\SelfDescribing::toString() has change and it is breaking the Matthias\SymfonyDependencyInjectionTest\PhpUnit\DefinitionHasMethodCallConstraint::toString()

If we run tests based on your library with a global phpunit binary, it fails. But it works with phpunit as a project dependency.

See more details here: sonata-project/SonataAdminSearchBundle#16 (comment)

And the related test case: https://github.com/sonata-project/SonataAdminSearchBundle/blob/72b0a5c5202ae8da33b5c1ea7936afde8e117e1d/Tests/DependencyInjection/Compiler/DatagridBuilderInjectionCompilerPassTest.php

We can't figure out why.

Maybe do you have an explanation?

Thanks.

Most of my services have a parameter for their classes. Currently, this needs to call:

$this->assertContainerBuilderHasService('my_service', '%my_service.class%');
$this->assertContainerBuilderHasParameter('my_service.class', 'My\Class');

This could be combined in a helper assertion, even using the suffix ".class" convention to remove duplicate parameters:

/**
 * Assert that a serviceId uses a parameter to use a class.
 * If no parameter name is given, the name of the serviceId suffixed with '.class' will be used.
 *
 * @param $serviceId
 * @param $expectedClass
 * @param null $expectedClassParameterValue
 */
public function assertContainerBuilderHasServiceWithParameteredClass($serviceId, $expectedClass, $expectedClassParameterValue=null)
{
    if(is_null($expectedClassParameterValue)) {
        // Assume the service has a default class parameter.
        $expectedClassParameterValue = $serviceId.'.class';
    }
    $this->assertContainerBuilderHasService($serviceId, '%'.$expectedClassParameterValue.'%');
    $this->assertContainerBuilderHasParameter($expectedClassParameterValue, $expectedClass);
}

Could you please create next release to make last changes available for install? For example, I need the PrependExtensionInterface::prepend() method invocation, and it is not available.

Using travis ENV, it is possible to run tests against multiple versions of symfony.

Example:

env:
   - SYMFONY_VERSION=2.1.*
   - SYMFONY_VERSION=2.2.*
   - SYMFONY_VERSION=2.3.*
   - SYMFONY_VERSION=2.4.*

before_script:
   - composer require symfony/dependency-injection:${SYMFONY_VERSION} --no-update
   - composer update --prefer-dist --no-interaction