This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Add a config option to change whether unread push notification counts are per-message or per-room #8820
Add a config option to change whether unread push notification counts are per-message or per-room #8820
Changes from 6 commits
cc9b865
795fb4e
f3a9a99
329e3d6
d3c6121
9b6fa97
ef3b9bd
9732e86
bed4d9f
f9ec52f
c05b7ed
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Having a test helper like this take a boolean is a bit odd, instead I think it would be clearer to take an
expected_count
argument.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.
That's true, and definitely generally the case. I think though in this case
_test_push_unread_count
isn't meant to be used as a helper. It's really only intended for saving on code duplication and running the above two tests.Perhaps I could rename it to something more clear?
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.
Sure, but abstracting via forking the code that way is a bit odd IMO.
Another option is to do the final assertions in the callers instead of in
_test_push_unread_count
?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.
My worry is mainly with anybody extending these tests in the future (which may not be a necessary worry and one that can be a bridge crossed when we get to it!), but my line of thinking is currently:
expected_count
we're toggling on a single variable when multiple may need to be changed in the future. A boolean forgroup_by_room
would then be simpler._test_push_unread_count
to the calling function, which could be something else that gets a bit messy in the future.However, I'm probably just making a mountain out of a molehill here, and taking your initial suggestion will likely be just fine for the current requirements of these tests.
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 don't follow this, I'm suggesting doing something like this:
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.
Oh, well I meant in terms of wanting to do more requests, however I forgot that everything we need to assert is stored in
self.push_attempts
anyways huh!That's quite elegant to check in a separate function. I think I'll give that a shot.
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.
Done in c05b7ed!