[SERVER-25456] suggestions for modularizing sharding unittest infrastructure Created: 05/Aug/16 Updated: 06/Dec/22 Resolved: 22/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Participants: | |||||||||
| Description |
|
Have a set of base test fixtures that provide different modules of functionality, example:
And a set of test fixtures that simulate different environments based on those modules, example:
That way, a unit test (or entire class's unit tests, such as for ShardingCatalogManager or ShardingState) that requires specific underlying functionality can use the appropriate underlying test fixture. If possible, the fixtures should be made such that one can easily be swapped for another, so that if a class starts requiring additional functionality, it's easy to swap in a more powerful underlying fixture. ===== Here are the main test fixtures that currently provide the needed functionality:
Here is an (incomplete) list of fixtures in sharding that inherit from the above:
|
| Comments |
| Comment by Esha Maharishi (Inactive) [ 22/Jan/19 ] |
|
greg.mckeon not really, this ticket is pretty old and outdated. We can probably just close it, which I will do. |