[SERVER-25563] create MongodTestFixture and make ConfigServerTestFixture extend it Created: 11/Aug/16 Updated: 19/Nov/16 Resolved: 01/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.14 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | Sharding 2016-08-29, Sharding 2016-09-19 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Goal: Be able to write unit tests that require both
but are shard-specific. Currently, at least the following projects require this:
This is a band-aid before more comprehensive improvements in PM-595. ShardTestFixture should:
ConfigServerTestFixture should additionally:
**The shard-specific unit tests may not actually use the DistLockCatalog and DistLockManager. Eventually, those classes should be owned by the ShardingCatalogManager, but currently they are accessed by the catalog manager through ShardingCatalogClient. Check if we can get away with just passing nullptr for the DistLockManager to the ShardingCatalogClient (if it's unused by tests), else must use DistLockCatalogImpl and ReplSetDistLockManager. |
| Comments |
| Comment by Githook User [ 01/Sep/16 ] |
|
Author: {u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}Message: |
| Comment by Dianna Hohensee (Inactive) [ 11/Aug/16 ] |
|
ConfigServerTestFixture already has ClusterRole::ConfigServer, a NetworkInterfaceMock, and real DistLockCatalog+DistLockManager. If you're use the TaskExecutor in the code you're testing on the config server, it will run fine with ConfigServerTestFixture and defining the onCommand for catching the network call as per testing usual – I'd expect TaskExecutor use cases that don't use the network should run fine as well because the TaskExecutors are set up like normal, just with a mock network. I don't have much to add about the shard test fixture. Just to second making the DistLockManager a nullptr because we don't have shard unit tests on it – I think? – and we're trying to generally do away with it so we aren't planning to make any. |
| Comment by Esha Maharishi (Inactive) [ 11/Aug/16 ] |
|
dianna.hohensee, spencer, renctan please review the description to see if any additional functionality is immediately required in either fixture. |