Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[FrameworkBundle] Fix test-container on kernel reboot, revert to returning the real container from Client::getContainer()#27501

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.

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

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:4.1fromnicolas-grekas:client-real-container
Jun 6, 2018

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedJun 5, 2018
edited
Loading

QA
Branch?4.1
Bug fix?yes
New feature?-
BC breaks?yes
Deprecations?no
Tests pass?yes
Fixed tickets#27494
LicenseMIT
Doc PR-

By makingClient::getContainer() return the new test container, we broke BC, as spotted in linked issue.

Always usestatic::$container in your tests instead.

While reverting to returning the real container, I noticed we have a serious design issue in the way the test container currently works: because the kernel can be rebooted, we cannot inject the container directly, but have to go through the kernel all the time. Fixing this forces doing a BC break on the constructor ofTestContainer. Since this is a new class and since it's mostly internal, I think we should do it now. I've marked the class as internal to further strengthen this.


privatefunctiongetPublicContainer()
{
$this->kernel->boot();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Haven't we made a change in 4.1 implying that booting an already booted kernel is not a no-op ? That's would be a bad side-effect then here.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I reverted the side-effect so this should be OK, but to be safe and strict, I replaced this call by an exception when the container is called while the kernel is not booted.

@stof
Copy link
Member

stof commentedJun 5, 2018

Btw, this also solves the issue we faced in#27037 as the only way to access private services now is through a new API (so any 3.4 deprecation is an actual one)

…rning the real container from Client::getContainer()
@arderyp
Copy link
Contributor

sounds good! Is there going to be accompanying documentation regarding what you (@nicolas-grekas) mentioned aboutstatic::$container and what you (@stof) mentioned about the "new API" for accessing the test container? I'm not sure I understand fully at the moment.

Copy link
Contributor

@pamilpamil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks good to me, fixes the BC break and works with Sylius :)

@fabpot
Copy link
Member

Thank you@nicolas-grekas.

@fabpotfabpot merged commit6764d4e intosymfony:4.1Jun 6, 2018
fabpot added a commit that referenced this pull requestJun 6, 2018
…ert to returning the real container from Client::getContainer() (nicolas-grekas)This PR was merged into the 4.1 branch.Discussion----------[FrameworkBundle] Fix test-container on kernel reboot, revert to returning the real container from Client::getContainer()| Q             | A| ------------- | ---| Branch?       | 4.1| Bug fix?      | yes| New feature?  | -| BC breaks?    | yes| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#27494| License       | MIT| Doc PR        | -By making `Client::getContainer()` return the new test container, we broke BC, as spotted in linked issue.Always use `static::$container` in your tests instead.While reverting to returning the real container, I noticed we have a serious design issue in the way the test container currently works: because the kernel can be rebooted, we cannot inject the container directly, but have to go through the kernel all the time. Fixing this forces doing a BC break on the constructor of `TestContainer`. Since this is a new class and since it's mostly internal, I think we should do it now. I've marked the class as internal to further strengthen this.Commits-------6764d4e [FrameworkBundle] Fix test-container on kernel reboot, revert to returning the real container from Client::getContainer()
@stof
Copy link
Member

stof commentedJun 6, 2018

@arderyp the PR introducing the test container made it available in 2 different ways:static::$container (which is totally new in 4.1) and$client->getContainer() (changing the API), whilestatic::$kernel->getContainer() was still returning the public container.
After this PR, only the newstatic::$container API exposes the test container.

@nicolas-grekasnicolas-grekas deleted the client-real-container branchJune 6, 2018 11:12
@arderyp
Copy link
Contributor

arderyp commentedJun 6, 2018
edited
Loading

awesome! So, for clarity's sake,

// on S3.4 WebTestCase extension$this->client = static::createClient();$this->container = $this->client->getContainer();

should be replaced with:

// on S4.x WebTestCase extension$this->client = static::createClient();$this->container = static::$container;

Is that right?

@nicolas-grekas
Copy link
MemberAuthor

This line is not needed:$this->container = static::$container;, as there is only one$container property per class, static or not, its the same here.

@arderyp
Copy link
Contributor

So no need tocreateClient() at all? Nice, thanks for the clarification!

@nicolas-grekas
Copy link
MemberAuthor

Yes you need it! I only told about the 2nd line.

@arderyp
Copy link
Contributor

Sorry, I'm an idiot... read too quickly, I understand now. Thanks again.

@fabpotfabpot mentioned this pull requestJun 25, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof left review comments

@fabpotfabpotfabpot approved these changes

+1 more reviewer

@pamilpamilpamil approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.1

Development

Successfully merging this pull request may close these issues.

8 participants

@nicolas-grekas@stof@arderyp@fabpot@pamil@xabbuh@jifer@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp