Skip to content

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?

What are the relevant issue numbers?

Merge request reports