Increase test coverage for oplog restore
General
Escalation
General
Escalation
Description
Environment
None
Activity
Show:
Done
Details
Details
Assignee
Boris Ilijic
Boris IlijicReporter
Boris Ilijic
Boris IlijicNeeds Review
Yes
Needs QA
No
Needs Doc
No
Story Points
3
Sprint
None
Fix versions
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist

Open Smart Checklist
Created November 28, 2024 at 9:51 AM
Updated January 14, 2025 at 2:15 PM
Resolved December 27, 2024 at 12:43 PM
Problem description
Oplog Restore is the core component of PBM which is used for any restore operation (physical, logical, PITR) and as such it’s mission critical. Over time we added different flows as part of it to support different use cases (selective restore, cloning namespace, …) which makes it even more complex.
To be able to develop it more faster (with more confidence to change existing source code) and to produce end result with more quality, it should be preferable to cover it with unit tests.
Solution proposition
Add unit tests for collection cloning feature, as well for all past use cases and that should roughly include:
cloning feature
selective restore
Mongo’s commands handling
handling of PBM’s related collections
config and admin collections handling
Acceptance Criteria
Established unit testing frame for Oplog Restore component
Test coverage for all important/major flows
For cloning feature do complete test coverage (all relevant functionality), for the existing feature try to cover as much as it’s possible.
QA and Documentation
Not relevant.