8000 test.service_container doesn't work with private shared:false services · Issue #27488 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

test.service_container doesn't work with private shared:false services #27488

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
vfalduto opened this issue Jun 4, 2018 · 5 comments
Closed

test.service_container doesn't work with private shared:false services #27488

vfalduto opened this issue Jun 4, 2018 · 5 comments
Labels
Bug FrameworkBundle Status: Needs Review

Comments

@vfalduto
Copy link
vfalduto commented Jun 4, 2018 •
edited
Loading

Symfony version(s) affected: 4.1.x

Description

test.service_container doesn't work with private shared:false services

App\MyService:
    shared: false
    public: false

When we try to load the MyService from the new "test.service_container" we have an exception :

 $client = static::createClient();
 $privateContainer = $client->getContainer();
 $privateContainer->get(App\MyService::class);

The 'AppMyService' service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.

Possible Solution

Additional context
@nicolas-grekas
Copy link
Member
nicolas-grekas commented Jun 5, 2018 •
edited
Loading

Hello, this is expected right now: the test container gives access to private services only if they have not been removed or inlined. Since non-shared services are almost always inlineable, you cannot get them.

What is the use case of fetching a non-shared service in a test case?

@vfalduto
Copy link
Author
vfalduto commented Jun 5, 2018

My non-shared service represents complex's operations on third party API with a session.
These operations are used by some manager who determine how to send the request.

In our tests, we only want to check if the complex's operations are well craft.
But the operations depends on other services with no need to mock for testing.

@nicolas-grekas
Copy link
Member

OK, then I would suggest you access the service via a public alias enabled in the test's config only. The current behavior is correct IMHO.

@nicolas-grekas
Copy link
Member
nicolas-grekas commented Jun 6, 2018 •
edited
Loading

I think this can be kept as a feature request. I would even extend it to private aliases: we could allow accessing remaining private services via their private alias if any (like the autowiring aliases.)
Implementing could be done in TestContainer*Pass in FrameworkBundle I suppose.

@nicolas-grekas nicolas-grekas mentioned this issue Jun 6, 2018
Merged
@nicolas-grekas
Copy link
Member

I changed my mind, see #27528 :)

nicolas-grekas added a commit that referenced this issue Jun 15, 2018
@nicolas-grekas
bug #27528 [FrameworkBundle] give access to non-shared services when …
ffa79ba 
…using test.service_container (nicolas-grekas)

This PR was merged into the 4.1 branch.

Discussion
----------

[FrameworkBundle] give access to non-shared services when using test.service_container

| Q             | A
| ------------- | ---
| Branch?       | 4.1
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #27488
| License       | MIT
| Doc PR        | -

Commits
-------

516ff5a [FrameworkBundle] give access to non-shared services when using test.service_container
@dbrekelmans dbrekelmans mentioned this issue May 18, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug FrameworkBundle Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nicolas-grekas @vfalduto @xabbuh @carsonbot
0