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

Interfering tests due to runtime cache #975

Open
s2b opened this issue Aug 18, 2024 · 0 comments
Open

Interfering tests due to runtime cache #975

s2b opened this issue Aug 18, 2024 · 0 comments

Comments

@s2b
Copy link
Contributor

s2b commented Aug 18, 2024

Fluid by default uses a runtime cache to avoid duplicate parsing/compiling of the same template files or strings. While this is reasonable for applications using Fluid, for Fluid's functional tests it can lead to interference between tests. This is why tests currently can't be executed in random order, but must always be run in the same order.

An example for this is ConstantViewHelperTest: Both renderThrowsExceptionOnNonStringValue() and renderThrowsErrorOnUndefinedConstant() use the same template string to test for an exception code. Depending on the order of the test execution, those codes are different because Fluid returns different exceptions for uncached and cached templates (which is an entirely different issue).

The runtime cache comes into effect in TemplateCompiler->has():

        if (isset($this->syntaxTreeInstanceCache[$identifier]) || class_exists($identifier, false)) {
            return true;
        }

(class_exists() is the relevant check)

and then later in TemplateCompiler->get(), where the class is instantiated. To fix this, we probably need to add an option to fluid to add a random value to the identifier per test run.

s2b added a commit that referenced this issue Aug 18, 2024
The cache is now removed between each test case, not between
each test class. This also unveiled one interference between two
`ForViewHelper` test cases.

Further interference is still present due to Fluid's runtime cache.
This is now documented in #975 to be fixed later.
s2b added a commit that referenced this issue Aug 18, 2024
The cache is now removed between each test case, not between
each test class. This also unveiled one interference between two
`ForViewHelper` test cases.

Further interference is still present due to Fluid's runtime cache.
This is now documented in #975 to be fixed later.
s2b added a commit that referenced this issue Aug 18, 2024
The cache is now removed between each test case, not between
each test class. This also unveiled one interference between two
`ForViewHelper` test cases.

Further interference is still present due to Fluid's runtime cache.
This is now documented in #975 to be fixed later.
s2b added a commit that referenced this issue Aug 18, 2024
The cache is now removed between each test case, not between
each test class. This also unveiled one interference between two
`ForViewHelper` test cases.

Further interference is still present due to Fluid's runtime cache.
This is now documented in #975 to be fixed later.
s2b added a commit that referenced this issue Aug 18, 2024
The cache is now removed between each test case, not between
each test class. This also unveiled one interference between two
`ForViewHelper` test cases.

Further interference is still present due to Fluid's runtime cache.
This is now documented in #975 to be fixed later.
s2b added a commit that referenced this issue Sep 8, 2024
This is an ugly workaround to prevent the interfering runtime
cache until #975 is resolved. Currently, subsequent test cases
are successful even if the rendering is modified to not inherit
ViewHelper namespaces to sub templates because they
re-use the "in-memory" template classes from previous tests.
As there is currently no way to configure this, we need to use
the ugly f:cache.disable ViewHelper in the affected template
to get robust testing results.
s2b added a commit that referenced this issue Sep 8, 2024
This is an ugly workaround to prevent the interfering runtime
cache until #975 is resolved. Currently, subsequent test cases
are successful even if the rendering is modified to not inherit
ViewHelper namespaces to sub templates because they
re-use the "in-memory" template classes from previous tests.
As there is currently no way to configure this, we need to use
the ugly f:cache.disable ViewHelper in the affected template
to get robust testing results.
s2b added a commit that referenced this issue Sep 8, 2024
This is an ugly workaround to prevent the interfering runtime
cache until #975 is resolved. Currently, subsequent test cases
are successful even if the rendering is modified to not inherit
ViewHelper namespaces to sub templates because they
re-use the "in-memory" template classes from previous tests.
As there is currently no way to configure this, we need to use
the ugly f:cache.disable ViewHelper in the affected template
to get robust testing results.
s2b added a commit that referenced this issue Sep 8, 2024
This is an ugly workaround to prevent the interfering runtime
cache until #975 is resolved. Currently, subsequent test cases
are successful even if the rendering is modified to not inherit
ViewHelper namespaces to sub templates because they
re-use the "in-memory" template classes from previous tests.
As there is currently no way to configure this, we need to use
the ugly f:cache.disable ViewHelper in the affected template
to get robust testing results.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant