Behavioral Encapsulation

A similar set of considerations occurs with methods and subordinate objects. As the implementation of an object’s behavior grows, the size and complexity of its methods increase, leading to refactoring. This refactoring creates new methods and classes, some of which represent purely internal models of behavior within the object. The Extract Method [REF] refactoring creates restricted methods. The Extract Class [REF] refactoring creates a new representation that may not need to be seen outside of the original context.

Refactoring like this tames the size and complexity of the software. However, the very size and complexity that suggests refactoring also suggests the need for testing. We may simplify a component or unit of our software by refactoring, but in the process we have also identified a critical step in a process or an actor in a relationship. The criticality of the new elements requires testing.

Many in the object-oriented development community say that you should not test private methods. This opinion certainly supports the strict encapsulation of the object. However, this position also holds a high chance of increasing the complexity and maintainability of our tests as we set up the conditions to invoke the extracted elements in all the necessary ways. The complexity incurred in the tests then becomes opportunity for errors in the tests, making our test cases less reliable. Direct testing of refactored implementations provides the same kind of simplification in our tests that refactoring produced in our production code.