Details
-
Improvement
-
Resolution: Won't Fix
-
Major - P3
-
None
-
None
-
None
-
Sharding
Description
Have a set of base test fixtures that provide different modules of functionality, example:
- storage engine: ServiceContextMongoDTest / ephemeralForTest
- network interface: ShardingTestFixture / uses NetworkInterfaceMock
- replication
- OpObserver
And a set of test fixtures that simulate different environments based on those modules, example:
- shard mongod: storage engine only
- shard mongod: network interface only
- shard mongod: storage engine + network interface
- config mongod: storage engine only
- config mongod: network interface only
- config mongod: storage engine + network interface
- mongos: network interface only
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:
- ShardingTestFixture (network interface only)
- ConfigServerTestFixture (network interface + storage engine, config-specific)
- ServiceContextMongoDTest (storage engine only)
Here is an (incomplete) list of fixtures in sharding that inherit from the above:
- BatchWriteExecTest
- AssignKeyRangeToZoneTestFixture
- ShardingCatalogTestFixture
- InfoLoggingTest
- DropColl2ShardTest
- ShardCollectionTest
- RemoveShardTest
- AsyncResultsMergerTest
- BalancerConfigurationTestFixture
- MigrationManagerTest
- ChunkManagerFixture
- ClusterIdentityTest
- possibly coming soon: test fixture for the range deleter
Attachments
Issue Links
- is depended on by
-
SERVER-25458 unit tests for ShardingState::initializeShardingAwarenessIfNeeded
-
- Closed
-