Bootstrapping Constructors
There is a basic dilemma in testing a well-encapsulated class that is so fundamental it is often overlooked: How do you know you have tested it correctly? You do not have access to the attributes of the class, so how do you verify that the constructor did its work correctly?
Sure, you can start with the most fundamental effect of a constructor and verify that a valid object was constructed. In the process, you also verify that no exceptions were thrown. But how do you verify that the internal state was initialized correctly (Listing 6-1)?
Listing 6-1: Testing object construction and the lack of exceptions
public void testMyObject() {
MyObject sut = new MyObject();
assertNotNull(sut);
}
If we didn’t insist on strong encapsulation, we could directly query the attributes. However, we all learned on our first day of Object-Orientation Indoctrination that this is a Bad Thing. We learned that the only allowed way to access our attributes should be with our getter methods.
But wait, should we really use methods that have not been tested to verify the behavior of another method? Do we have any other choices? In short, we may—depending on the language—but none that are good enough to use on such a fundamental and consistent basis (Listing 6-2).
Listing 6-2: Using a getter to verify constructor state
public void testMyObject() {
MyObject sut = new MyObject();
assertNotNull(sut);
assertEquals(expectedValue, sut.getAttribute());
}
Let’s resolve this seemingly circular dependency before we proceed. The key to this apparent dilemma is to realize that in normal cases, it is sufficient for the constructor and the simple setters and getters to behave in a manner that is consistent with expectations. Essentially, we are saying, “If it looks like a class and acts like a class, it is safe to treat it like a class.”
Which cases are not part of the aforementioned “normal cases,” and what should we do if we encounter these deviations? Abnormal cases occur when the constructor initializes hidden state or the getters do more than simply pass the value of an attribute. In the former case, we can use techniques to give our tests privileged access to our classes, described in Chapter 9. In the latter case, I would suggest that the methods should be renamed to reveal their more complex nature and that they should not masquerade as getters.
A Mathematical View of Tests
For those who tend toward the mathematical, I have an analogy for tests that parallels two of the traditional approaches to mathematical proof. We are all familiar with the typical deductive proof. Given some set of fundamental facts or assumptions, we build a sound logical argument that leads us to a conclusion. As long as the initial assumptions are valid and the logical argument remains sound, we hold the conclusion as truth. System or integration tests are like deductive proofs. Given a set of initial conditions of the software, we apply a set of operations on the software and declare the software correct if the resulting state agrees with expectations. In fact, the given/when/then format1 of behavior-driven development frameworks reinforces this interpretation. The tests generally stand alone. Collectively, they verify different aspects of the system that together serve to verify the whole system, ideally by covering all aspects of the system.
1. This has become known as the Gherkin format of test specification, deriving from its association with the Cucumber BDD testing framework.
Unit tests are different. Unit tests may be seen as a deductive proof of the unit under test, but even that requires a bit of inference. The approach to bootstrapping constructors just described can be seen as the basis case for an inductive proof. Inductive proofs demonstrate the premise for a basis case and then demonstrate the inductive step: for any case n, the premise also holds for the n+1 case. Each step builds upon the next. Within the tests for a unit, the correctness of the more complex behaviors of the unit depend on the correctness of construction and basic attribute management as shown in Figure 6-1. In the larger context, unit tests for leaf components, those components that depend only on system libraries, are the basis case. Using the earlier heuristic of unit tests only testing the value added by the unit under test, each successful unit’s tests provide an inductive step toward proving the correctness of the system.
In mathematics, both forms of proof are functionally equivalent and correct ways to support a conclusion. However, software systems are not mathematically rigorous systems. This analogy can serve as a useful model to differentiate the different approaches to testing, but neither is sufficient in and of itself to verify the system.