Shouldnt we deprecate thenull scenario first? So other conditional deprecations are practically not needed.

That's the point of this PR:#19668 is deprecating much more than technically required to enhance the dumped containers in 4.0. In fact, even if I listen to the "best practice" arguments in#19668, we know that forbidding altogether not-best-practices can break legitimate edge-case use cases (remember the deprecation of "get" in non dumped containers that we reverted). Thus, I'm not sure at all we should merge#19668 - but I'm sure we should merge this one, because it will make SF4 betterat the technical level.

👍

Thank you@nicolas-grekas.

Hi@nicolas-grekas

I am testing SF 3.3BETA1 and I've got a trouble with that Pull Request:

• What about mock of service in functional test ?

When I try to replace Service with$kernel->getContainer()->set() I have a deprecation notice:

Setting the "SERVICE" pre-defined service is deprecated since Symfony 3.3 and won't be supported anymore in Symfony 4.0

What is my solution for this kind of functional tests ?

Thanks for the answer.

By loading dedicated config files in your tests? Seehttps://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Tests/Functional/CachePoolClearCommandTest.phphttps://github.com/symfony/symfony/tree/master/src/Symfony/Bundle/FrameworkBundle/Tests/Functional/app/CachePoolClear for inspiration

@xkobal injecting a PHPUnit mock to replace a service instance is a very fragile setup: if any other services depending on this service got instantiated already before yourset call, it will keep using the other object rather than the mock. Replacing service instances at runtime cannot work reliably (which is exactly why we deprecated it).
Loading specific config for functional tests is indeed a much more reliable alternative. It does not allow to use mocks generated by PHPUnit though, or at least not without much pain. But it can be used by injecting hand-crafted mocks (i.e. custom implementations of your interface)

The config approach is indeed much stronger. I also used to mock services with theset() method, heavily inspired byhttp://blog.lyrixx.info/2013/04/12/symfony2-how-to-mock-services-during-functional-tests.html (at the boot before any service gets used by the test).

I'm agree with you on that point, and I'll change my tests, but, thats a way to test services, very very used on a lot of project ! It'll be a painful point for a lot of projects to upgrade to SF 3.3

Thanks for your answers.

Note that you don'tneed to fix the deprecations when moving to 3.3.
But youwill when moving to 4.0.

I never upgrade a project letting some deprecations, our CI is failing on phpunit tests when there are some deprecations, but that's our choice, others can ignore them.

Well, you can mark these tests as@legacy to avoid making them fail temporarily, to give you time to migrate the tests, if that takes time. This is the whole point of deprecations: you can migrate progressively (I alsoprefer removing deprecations as fast as possible, but for some of them, it may require more time)

This is going to be difficult for my use case -- I replace guzzle clients with guzzle mock handlers loaded with responses (per test), and I validate both the response and the request made.

@chalasr "use config files" assumes that a service can be reconfigured (or replaced) by way of configuration alone, and also that tests can all use the same configuration.

@stof We're talking about testing here -- tests are supposed to be fragile.

This isn't looking good. Am I going to have to forgo booting a kernel and just build my services by hand before testing them? Or, perhaps, I create intermediary objects that can know how to replace themselves on demand? Either way, I have to take over work that I could previously count on my framework to do.

Please open an issue to discuss this.

I'm adding a comment to#23311.

You should open a new issue really. Comments on closed tickets aren't tracked.

Thanks@chalasr I've opened#23772