Make notification_service spec DRYer by making some tests reusable
What does this MR do? [ And ] Why was this MR needed?
It refactors notification_service spec and makes some code reusable.
It came up when I worked on #23460 (closed) . The spec for 'participants' notifications in notification_service for both issue and merge_request is pretty simple but it was fully copied without significant changes 8-9 times (!!!) for EVERY situation you need to notify this group of users which caused to file to extra growth and not being very DRY. And I love DRY. Since the spec is already too messy and most likely gonna to increase the size nearest time, I decided to refactor those parts.
Are there points in the code the reviewer needs to double check?
I don't think I messed up with logic. I'd be very appreciated to hear feedback about code style/"quality". Is anything I could do to make it even better like naming conventions, rspec stuff, etc?
Does this MR meet the acceptance criteria?
-
Changelog entry added -
Documentation created/updated -
API support added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master
(if it does - rebase it please) -
Squashed related commits together