-
Notifications
You must be signed in to change notification settings - Fork 93
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
Comments
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
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
: BothrenderThrowsExceptionOnNonStringValue()
andrenderThrowsErrorOnUndefinedConstant()
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()
:(
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.The text was updated successfully, but these errors were encountered: