TABLE OF CONTENTS In an averagely complex application, an object can hardly do without the cooperation of many other objects of the same or another class. So how can we test an object that depends on so many others? The most pragmatic and (probably) intuitive way out of this dilemma is the bottom-up approach: we begin our development and testing with the classes that build themselves on system-owned classes. Then we use these tested components to build independent classes.
This approach is called bottom-up because we start from the very bottom, with the most concrete objects, working our way up to the more abstract components. We saw in Chapter 3, Section 3.2 that working top-down (or outside-in) is easier in the test-first approach. In that section, we also identified problems caused by the dependence of various classes upon each other and external sources. This chapter shows how to avoid these dependencies or subsequently eliminate them in many cases.
One important unit-testing rule comes up over and over again: a single test case should be as local as possible; that is, it should test only the object we are currently dealing with and not all the others it requires for its job or with whom it cooperates and to which it delegates tasks. One way to come a step closer to the goal of maximum independence of a test is through the use of dummy objects. This means that we replace part of our objects...
