[SERVER-64136] Add capacity to mock commands run on DBDirectClient Created: 02/Mar/22 Updated: 06/Dec/22 Resolved: 26/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Didier Nadeau | Assignee: | [DO NOT USE] Backlog - Server Serverless (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Serverless
|
| Participants: |
| Description |
|
ShardSplitDonorService uses DBDirectClient for operations such as `replSetReconfig`. This forces us to define a mock "replSetReconfig" command globally within `shard_split_donor_service_test.cpp`, otherwise this command does not exist and the test fails.
This could create issues is the real implementation of "replSetReconfig" is linked (multiple registration of the same commands) or if the mock cause unintended behavior in other test (registration is global, it can't be turned on/off depending on the test).
MockRemoteDBServer provides a `setCommandReply` interface that seemed promising, but it can't be used as DBDirectClient does not invoke MockRemoteDBServer and does it work locally instead. Furthermore the `setCommandReply` does not provide the ability to check the command has been called, or with which arguments.
We want to be able to mock commands with some granularity control and with the capacity to check its input/validate it's been called. |
| Comments |
| Comment by Matt Broadstone [ 26/May/22 ] |
|
See the attached POC for inspiration on how to mock DBDirectClient tests. Closing this as "Won't Do" since we have made it a goal of PM-2399 to make that interface unit-testable, and expect that code will be migrated to that interface in the future. |
| Comment by Matt Broadstone [ 28/Apr/22 ] |
|
POC: https://gist.github.com/mbroadst/1c9758073db992b436f632cd4a031247 |