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
TASK: Allow to enable Fusion caching for Behat tests #5014
TASK: Allow to enable Fusion caching for Behat tests #5014
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, +1 by reading.
You write, that this is using the TransientMemoryBackend - is that the default for testing context?
Yes, it is. But it seems not to work in the Pipeline. I'll change it for Testing/Behat to FileBackend |
Ahh, It was just the first commit failing.... so yes, it works. |
Scenario: Render a cached prototype and check if rerendering doesn't happen on second try | ||
When I execute the following Fusion code: | ||
"""fusion | ||
test = Neos.Neos:Test.ContentCache { | ||
foo = 'some-cached-string' | ||
} | ||
""" | ||
Then I expect the following Fusion rendering result: | ||
""" | ||
some-cached-string | ||
""" | ||
When I execute the following Fusion code: | ||
"""fusion | ||
test = Neos.Neos:Test.ContentCache { | ||
foo = 'some-other-string' | ||
} | ||
""" | ||
Then I expect the following Fusion rendering result: | ||
""" | ||
some-cached-string | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm i understand the idea but this is not how fusion works normally ... it. doesnt change its fusion code.
I rather have the test follow how fusion works:
- have one big setup
- trigger different entrypoints or have different outside word variables
or do you think differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, maybe. But actually the test work as expected 🤔 And actually this test it's just ensuring, that a caching is enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but if I think about this...
The tests I need this for, will look the same. I need somehow check, if a already cached entry got changed, because of a cache invalidation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imo what we want to test is this:
Given I have Fusion content cache enabled
And I have the following Fusion setup:
"""fusion
include: resource://Neos.Fusion/Private/Fusion/Root.fusion
test = Neos.Fusion:Value {
value = ${myVariable}
@cache {
mode = 'cached'
entryIdentifier {
test = 'test'
}
}
}
"""
When i render the path 'test' with the following context:
"""json
{myVariable:'initial'}
"""
I Expect the output 'initial'
When i render the path 'test' with the following context:
"""json
{myVariable:'other'}
"""
I Expect the output 'initial'
that way the test does exactly what we do when we run fusion in multiple requests.
Changing the fusion configuration at runtime might work in this test environment but is not how fusion is supposed to work and this behaviour might actually be buggy. So id prefer that ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like and IMO we could have a test for both scenarios
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, IIRC this is exactly the preparation for such tests to cover the behaviour of the content cache flusher, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to keep it as it is. We use this existing feature already in multiple test cases and all I want to add with this PR is the ability to enable tjhe content cache. I guess an change in "how to test fusion" would be nice, but is currently not on my todo list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dlubitz for the record: my blabbering above was meant as "this could be done as follow up", I already approved this one.
However, Marc-Henry has a point ofc. We should try to make those tests as realistic as possible.
@mhsdesign what do you think of merging this one as is and then tweaking this (and the other!) features along the lines you suggested?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, yes... I know. I was just trying to convince @mhsdesign to postpone that 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay i see im overruled thats fine ^^. And i also agree that its unfair to block denny while i approved the initial pr that introduced this syntax #4641 i was thinking at that time that this might be a good idea :) So its definitely no drama and we would gain a lot if we have tests regarding the content cache in any syntax so thanks for dealing with this ❤️
Allows to enable the ContentCache for Fusion renderings in Behat tests. The cache uses the TransientMemoryBackend and gets flushed before each scenario.