0

I'm having an issue with running our functional test suite on our Symfony application when using the following config (some information redacted):

  App\Bundle\Controller\Controller:
    arguments:
      - '@datatable'
      - '@filtermanager'
      - '@App\Bundle\Service\FilterService'
      - '@translator'
    tags: ['container.service_subscriber']
    calls: [['setContainer', ['@Psr\Container\ContainerInterface']]]

We are currently running Symfony 3.4, however upgrading to 4.4 soon so attempting to write compatible code, hence declaring controllers as services and using DI for the services instead of getting from the container. When doing this, we noticed we were unable to access some of the Symfony methods, such render(), createForm(), getDoctrine() etc, as these needed the container.

After a long session on Google, I came across this article, which mentioned that autowiring normally calls the set container method (like in the last line of my code example). This then allows the controller to use those specific Symfony methods as it has access to a slimmed down version of the container.

Anyhow, in doing the above, it made our functional test suite go from taking 12 minutes to anywhere between 1-3 hours. As of yet there are no functional tests for the controller, or for anything to do with this code. I also noticed no hinderance in performance when testing the behaviour manually.

I've also tried the following:

  App\Bundle\Controller\Controller:
    autowire: true

as we do have autowiring on, but only for one directory. In doing the above, the code all worked correctly, but the tests still took a similarly long time

I'm hoping that someone has an explanation for why this is happening, or possibly an answer of how to fix it. I'd like to try and avoid injection things like FormFactory and EntityManager manually, as it seems a bit pointless when these helper methods are available.

TIA

  • 2
    Maybe your test suite is rebuilding the complete cache between each test? All the wiring is cached so I can't think of any reason for a general slowdown unless the cache was constantly being rebuilt. – Cerad Aug 25 '20 at 11:56
  • @Cerad , thanks, I'd not considered that. I'll have a look and see if I can find any evidence of this. – Twisterr1000 Aug 25 '20 at 13:04

1 Answers1

0

As a couple of posts mentioned elsewhere, the error that was occuing was due to the jms/di-extra-bundle. When we removed this, the test speed increased drastically