Currently, the Sharding unit-tests are scattered across at least 5 different binaries and it is (a) hard to decide where exactly to place a new unit-test and (b) hard to figure out which one exactly to compile when making changes. The unit-tests should ideally be combined into just 2 binaries: one under db/s and one under s/. However, because the ConfigServerTestFixture and the ShardServerTestFixture register different static objects on the OperationContext (the VectorClock is one such notable example), it is not possible to put the two of them in the same binary.

However, we should at least make them into 3 binaries:

• db_s_shard_server_test: All tests, which use the ShardServerTestFixture and logically are tests, which exercise behaviour specific to how a Shard would act. These tests have a storage engine, but the ConfigShard is abstracted through the NetworkInterfaceMock and all communication with the ConfigServer needs to be emulated through that mock.
• db_s_config_server_test: All tests, which use the ConfigServerTestFixture and logically are tests, which exercise behaviour specific to how a ConfigServer would act. These tests have a storage engine, but the ConfigShard is actually a LocalShard so operations against it go through the DBDirectClient.
• s_test: All tests, which use the ShardingRouterTestFixture and logically are tests, which exercise behaviour specific to how a Router would act. These tests do not have a storage engine and all Shard communication needs to be abstracted through the NetworkInterfaceMock.