[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:
Depends
is depended on by SERVER-25871 make ShardingStateTest extend MongodT... Closed
is depended on by SERVER-25872 make DistLockCatalogFixture and ReplS... Closed
is depended on by SERVER-25873 make ReplSetDistLockManagerFixture ex... Closed
Related
related to SERVER-24702 Remove remnants of ShardingCatalogMan... Closed
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

  • network interface
  • storage engine

but are shard-specific. Currently, at least the following projects require this:

  • All Nodes Shard Aware
  • Range Deleter
  • Remove DistLock from Split and Merge

This is a band-aid before more comprehensive improvements in PM-595.

ShardTestFixture should:

  • use NetworkInterfaceMock (for network interface)
  • extend ServiceContextMongoDTest (for storage engine)
  • have ClusterRole::ShardServer
  • have ShardingCatalogClientImpl
  • maybe have a real DistLockCatalog and DistLockManager**
  • have a real OpObserver

ConfigServerTestFixture should additionally:

  • have ClusterRole::ConfigServer
  • have ShardingCatalogManagerImpl
  • have a mock network for addShard and executor for addShard
  • definitely have a real DistLockCatalog and DistLockManager**

**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: SERVER-25563 create MongodTestFixture and make ConfigServerTestFixture extend it
Branch: master
https://github.com/mongodb/mongo/commit/518df32a41a080fdbf042b2fc3e6d7c38ad97980

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.

Generated at Thu Feb 08 04:09:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.