Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added compatibility with PHPUnit 10 #3813

Open
wants to merge 5 commits into
base: 3.x
Choose a base branch
from

Conversation

SiebelsTim
Copy link

fixes #3810

@SiebelsTim
Copy link
Author

This is a breaking change. Are we allowed to do these on 3.x? Do we have something like an UPGRADE.md that I can add this to?

I did not modify Twig's own tests as we can do that when/if we upgrade to PHPUnit 10. However, this is needed so that Twig's users can upgrade themselves to PHPUnit 10, when they are using IntegrationTestCase

src/Test/IntegrationTestCase.php Outdated Show resolved Hide resolved
src/Test/IntegrationTestCase.php Outdated Show resolved Hide resolved
@SiebelsTim SiebelsTim force-pushed the 3810-compat-phpunit10 branch 2 times, most recently from 18e8edd to 2e99384 Compare February 15, 2023 17:26
@SiebelsTim
Copy link
Author

I've pushed a different concept. I dislike that it is quite complex.

I'm open to suggestions, please tell me what you think.

src/Test/BaseIntegrationTestCase.php Outdated Show resolved Hide resolved
src/Test/IntegrationTestCasePhpUnit10.php Outdated Show resolved Hide resolved
@SiebelsTim
Copy link
Author

I think I resolved most of the comments. Naming things is hard though.

Furthermore, I noticed that there is also NodeTestCase. That is much harder to fix. Every method in that class needs to be static. I only see the option to copy the class and I even might be fine with copying, as the class is much smaller compared to IntegrationTestCase.

But even then, upgrading to it is much harder, as we use $this->createMock() in the data provider which we want to turn static.

@stof
Copy link
Member

stof commented Feb 16, 2023

But even then, upgrading to it is much harder, as we use $this->createMock() in the data provider which we want to turn static.

The replace test case must be refactored in a way where the mock is created in the test, not in the data provider.

@SiebelsTim SiebelsTim requested a review from stof February 22, 2023 13:58
src/Test/IntegrationTestCase.php Outdated Show resolved Hide resolved
src/Test/BaseTemplateIntegrationTestCase.php Outdated Show resolved Hide resolved
static::assertNodeCompilation($source, $node, $environment, $isPattern);
}

public static function assertNodeCompilation($source, Node $node, Environment $environment = null, $isPattern = false)
Copy link
Contributor

@GromNaN GromNaN Mar 16, 2023

Choose a reason for hiding this comment

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

Could you check why this method needs to be static, same for getCompiler and getEnvironment?

Copy link
Member

Choose a reason for hiding this comment

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

keeping getEnvironment non-static would be more flexible (test cases could then use mocks in it if they need it). so I would keep all these non-static

Copy link
Author

Choose a reason for hiding this comment

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

When doing so, you cannot use them in data providers anymore. I thought it would be more valueable to allow them to be used in data providers.
We use getCompiler in one test internally.

I don't have a strong opinion on this though.

I've pushed a commit turning this non-static again.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain de bit more how you use getCompiler in the dataprovider ?

Copy link
Author

Choose a reason for hiding this comment

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

\Twig\Tests\Node\DeprecatedTest uses Compiler::getVarName() to build the expected php source code that is compiled from a Node.

I suppose we should rather hardcode __internal_compile_0 into the expected string. What do you think?
I pushed a commit doing that on top of this branch in case you agree.

@SiebelsTim SiebelsTim requested review from GromNaN and stof and removed request for stof and GromNaN March 23, 2023 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

IntegrationTestCase: Compatibility with PHPUnit 10
4 participants