[9.x] Fix EventFake::assertListening()
for asserting string-based observer listeners
#42289
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #42193
Widening the matching mechanism for string-based assertions (from
Str::endsWith('@handle')
toStr::contains('@')
) allowed the underlying logic to unexpectedly handle Observer event assertions, transforming the$actualListener
from a string to an array without also transforming the$expectedListener
from a string to an array (where the assertion is a string).(NB: This wasn't breaking any production code, only some tests that used string-based event listener assertion for observers instead of array-based assertion)
This was missed due to a lack of testing around Observer listener assertion in the EventFake test suite. So this PR contains new tests to cover this scenario.
It addresses the issue by explicitly parsing a string-based
$expectedListener
assertion when the$actualListener
is also a string (now always converted to an array as of #42193), so that the$expectedListener
correctly matches the parsed$actualListener
.