Task #6375
Story #4463: Incorporate Node Replication Policy into replication processing
Task #6372: rehabilitate ReplicationManager "unit" tests
Refactor out dependency on a working CN
30%
Description
The ReplicationManager tests depended on the D1Client.CN_URL to be able to return a v2.NodeList, which we can't do right now.
Unit tests should not depend on external resources, so this needs to be removed. Unfortunately, this dependency is coded in the ReplicationManager itself, and there isn't a way to configure from the test code. D1Client.getCN() makes a call out to the D1Client.CN_URL to retrieve the NodeList, and throws an exception if it can't find it, or can't get the node list.
If this type of exception checking is something cn_replication wants, we need to fully incorporate new libclient features to instantiate a mock cn instance that gets picked up by D1Client, or SetitingsContextNodeLocator. Otherwise we should use D1NodeFactor.getCN(baseUrl), and remove any upfront checking.
History
#1 Updated by Rob Nahf about 10 years ago
For now, ReplicationManager and ReplicationService fallback to an unchecked creation of a CNode if d1Client.getCN() throws and exception, logging warnings along the way. Revisit during v2 refactoring
#2 Updated by Robert Waltz about 10 years ago
- Target version changed from 2014.16-Block.2.4 to CCI-1.5.0
#3 Updated by Robert Waltz about 10 years ago
- Target version changed from CCI-1.5.0 to CCI-1.5.1
#4 Updated by Rob Nahf almost 10 years ago
- Target version changed from CCI-1.5.1 to CCI-2.0.0
#5 Updated by Rob Nahf over 8 years ago
- % Done changed from 90 to 30
D1Client via SettingsContextNodeLocator allows instantiation of a test CN class via the property "D1Client.cnClassName". It may allow a workaround to refactoring all of the D1Client.getCN() calls in d1_replication (10 calls in 5 classes).
