I originally published this on March 2, 2005.
Unless I’m publishing an API for general use, I don’t worry about testing method parameters against null. It’s too much code and too many duplicate tests. Besides, I would be testing the wrong thing.
When a method receives null as a parameter, the invoker—and not the receiver—is missing a test.
I originally published this on January 3, 2005. One of my other postings links to this article, so I wanted to bring it back to life. Thanks to James Breen for pointing out the broken link to me.
In working with Pat Welsh I had occasion to describe in a rather pithy way when to fake and when to mock, so I thought I’d share that with you.
To be clear, I mean “mock” in the sense of interaction-based testing with mock objects, and I mean “fake” in the sense of state-based testing with fakes or stubs. Google if you need a stronger definition of those terms, but they suit me for now.
Note that I use the term “stub” when I used to say “fake”.
So then, I want to test some object in isolation from the rest of the system. In broad terms, I need to write tests to answer two essential questions:
For the first kind of test, I generally mock; and for the second kind of test, I generally fake.
Put another way, I lean on interaction-based testing to verify how my object talks to its collaborators; but I lean on state-based testing to verify how well that object listens.
Recently, “Guest” commented about my Agile 2009 tutorial, Integration Tests Are A Scam. “Guest” wrote this:
A Mars rover mission failed because of a lack of integration tests. The parachute system was successfully tested. The system that detaches the parachute after the landing was successfully – but independently – tested. On Mars when the parachute successfully opened the deceleration “jerked” the lander, then the detachment system interpreted the jerking as a landing and successfully detached the parachute. Oops. Integration tests may be costly but they are absolutely necessary.
I don’t doubt the necessity of integration tests. I depend on them to solve difficult system-level problems. By contrast, I routinely see teams using them to detect unexpected consequences, and I don’t think we need them for that purpose. I prefer to use them to confirm an uneasy feeling that an unintended consequence lurks.
Let’s consider a clean implementation of the situation my commenter describes. I see this design, comprising the lander, the parachute, the detachment system, an accelerometer and an altimeter. A controller connects all these things together. Let’s look at the “code”, which I’ve written in a fantasy language that looks a little like Java/C# and a little like Ruby.
Ashley Moran has posted a working Ruby version of this example. If you speak Ruby, then I highly recommend looking at that example after you’ve read this.}
Controller.initialize() { parachute = Parachute.new(lander) detachment_system = DetachmentSystem.new(parachute) accelerometer = Accelerometer.new() lander = Lander.new(accelerometer, Altimeter.new()) accelerometer.add_observer(detachment_system)} Parachute { needs a lander open() { lander.decelerate() } detach() { if (lander.has_landed == false) raise "You broke the lander, idiot." }} AccelerationObserver is a role { handle_acceleration_report(acceleration) { raise "Subclass responsibility" }} DetachmentSystem acts as AccelerationObserver { needs a parachute handle_acceleration_report(acceleration) {} if (acceleration <= -50.ms2) { parachute.detach() } }} Accelerometer acts as Observable { manages many acceleration_observers report_acceleration(acceleration) { acceleration_observers.each() { each.handle_acceleration_report(acceleration) } }} Lander { needs an accelerometer needs an altimeter decelerate() { // I know how much to decelerate by accelerometer.report_acceleration(how_much) }} I need to test what happens when I open the parachute. The lander should decelerate.
testOpenParachute() { parachute = Parachute.new(lander = mock(Lander)) lander.expects().decelerate() parachute.open() } Since this test expects the lander to decelerate, I have to test that. When the lander decelerates, the accelerometer should report its deceleration.
testLanderDecelerates() { accelerometer = mock(Accelerometer) lander = Lander.new(accelerometer) accelerometer.expects().report_acceleration(-50.ms2) lander.decelerate()} Since this test shows that the accelerometer can report acceleration of -50 m/s2, I have to test that.
testAccelerometerCanReportRapidAcceleration() { accelerometer = Accelerometer.new() accelerometer.add_observer(observer = mock(AccelerationObserver)) observer.expects().handle_acceleration_report(-50.ms2) accelerometer.report_acceleration(-50.ms2)} Since this test shows that any acceleration observer must be prepared to handle an acceleration report of -50 m/s2, I have to test that.
First, the general test for the contract of the interface:
AccelerationObserverTest { testAccelerationObserverCanHandleRapidAcceleration() { observer = create_acceleration_observer() // subclass responsibility this_block { observer.handle_acceleration_report(-50.ms2) }.should execute_without_incident } } Now the test for DetachmentSystem, which acts as an AccelerationObserver. What should it do if it detects such sudden deceleration? It should detach the parachute.
DetachmentSystemTest extends AccelerationObserverTest { // I inherit testAccelerationObserverCanHandleRapidAcceleration() create_acceleration_observer() { DetachmentSystem.new(parachute = mock(Parachute)) parachute.expects().detach() }} You might find that easier to read this way, by inlining the method create_acceleration_observer():
DetachmentSystemTest { testRespondsToRapidAcceleration() { detachment_system = DetachmentSystem.new(parachute = mock(Parachute)) parachute.expects().detach() this_block { detachment_system.handle_acceleration_report(-50.ms2) }.should execute_without_incident }} Since this test expects the parachute to be able to detach, I have to test that. Now, detaching only works if we’ve landed. (I’ve simplified on purpose. Suppose the parachute can’t survive a drop from any height. It’s easy to add that detail in later.)
ParachuteTest { testDetachingWhileLanded() { parachute = Parachute.new(lander = mock(Lander)) lander.stubs().has_landed().to_return(true) this_block { parachute.detach() }.should execute_without_incident } testDetachingWhileNotLanded() { parachute = Parachute.new(lander = mock(Lander)) lander.stubs().has_landed().to_return(false) this_block { parachute.detach() }.should raise("You broke the lander, idiot.") }} Hm. I notice that parachute.detach() might fail. But I just wrote a test that uses parachute.detach() and doesn’t yet show how it handles that method failing. I have to test that.
DetachmentSystemTest { testRespondsToDetachFailing() { detachment_system = DetachmentSystem.new(parachute = mock(Parachute)) parachute.stubs().detach().to_raise(AnyException) this_block { detachment_system.handle_acceleration_report(-50.ms2) }.should raise(AnyException) }} Hm. So handling an acceleration report of -50 m/s2 can fail. Who might issue such a right? The accelerometer. Since the detach system doesn’t handle this failure, I have to test what the accelerometer does when issuing an acceleration report might fail.
testAccelerometerCanRespondToFailureWhenReportingAcceleration() { accelerometer = Accelerometer.new() accelerometer.add_observer(observer = mock(AccelerationObserver)) observer.stubs().handle_acceleration_report().to_raise(AnyException) this_block { accelerometer.report_acceleration(-50.ms2) }.should raise(AnyException)} It turns out that the accelerometer might fail when reporting acceleration of -50 m/s2. When might it do that? When the lander decelerates. What happens then?
testLanderDeceleratesRespondsToFailure() { accelerometer = mock(Accelerometer) lander = Lander.new(accelerometer) accelerometer.stubs().report_acceleration().to_raise(AnyException) this_block { lander.decelerate() }.should raise(AnyException)} Hm. So decelerating could fail! All right, who causes the lander to decelerate? That code might fail. Oh yes… the parachute opening!
testOpenParachuteRespondsToFailure() { parachute = Parachute.new(lander = mock(Lander)) lander.stubs().decelerate().to_raise(AnyException) this_block { parachute.open() }.should raise(AnyException)} So opening the parachute could fail! We probably want to nail down when that happens. We have a test that shows us when:
testDetachingWhileNotLanded() { parachute = Parachute.new(lander = mock(Lander)) lander.stubs().has_landed().to_return(false) this_block { parachute.detach() }.should raise("You broke the lander, idiot.")} So the parachute opening could cause it to detach because the lander hasn’t landed yet. I don’t know about you, but I think the parachute provides the most value when its helps the lander land, and not once it has landed. That tells me that someone, somewhere needs to handle the exception that detach() would raise, or at least prevent detach() from happening while the altimeter reads above a few meters off the ground.
testDoNotDetachWhenTheLanderIsTooHighUp() { altimeter = mock(Altimeter) altimeter.stubs().altitude().to_return(5.m) DetachmentSystem.new(parachute = mock(Parachute)) parachute.expects(no_invocations_of).detach() detachment_system.handle_acceleration_report(-50.ms2) // ???} In writing this test, I see that in order to stop the detachment system from telling the parachute to detach, it needs access to the altimeter.
Integration problem detected. When I wire the detachment system up to the altimeter, even the collaboration test shows how to ensure that the parachute doesn’t detach in this kind of dangerous situation.
testDoNotDetachWhenTheLanderIsTooHighUp() { DetachmentSystem.new(parachute = mock(Parachute), altimeter = mock(Altimeter)) altimeter.stubs().altitude().to_return(5.m) parachute.expects(no_invocations_of).detach() detachment_system.handle_acceleration_report(-50.ms2)} This means I have to add the following production behavior.
DetachmentSystem acts as AccelerationObserver { needs a parachute needs an altimeter // NEW! handle_acceleration_report(acceleration) {} if (acceleration <= -50.ms2 and altimeter.altitude() < 5.m) { parachute.detach() } }} Integration problem solved with no integration tests. Instead, I have a bunch of collaboration tests, one important contract test, and the ability to notice things a systematic approach to choosing the next test, which I describe in the comments below. Any questions?
Dan Fabulich rightly jumped on me for using the phrase “an ability to notice things” just a little earlier in this article. I choose that phrase lazily because I didn’t want to patronize you by writing, “an ability to perform basic reasoning”. Oops. I thought about how I choose the next test, and I decided to take the time to include that here. Enjoy.
In this example, I used no magic to choose the next test; but rather some fundamental reasoning.
Every time I say “I need a thing to do X” I introduce an interface. In my current test, I end up stubbing or mocking one of those tests.
(See A sign you’re mocking too much for more about when I avoid interfaces and when I routinely create them.)
Every time I stub a method, I make an assumption about what values that method can return. To check that assumption, I have to write a test that expects the return value I’ve just stubbed. I use only basic logic there: if A depends on B returning x, then I have to know that B can return x, so I have to write a test for that.
Every time I mock a method, I make an assumption about a service the interface provides. To check that assumption, I have to write a test that tries to invoke that method with the parameters I just expected. Again, I use only basic logic there: if A causes B to invoke c(d, e, f) then I have to know that I’ve tested what happens when B invokes c(d, e, f), so I have to write a test for that.
Every time I introduce a method on an interface, I make a decision about its behavior, which forms the contract of that method. To justify that decision, I have to write tests that help me implement that behavior correctly whenever I implement that interface. I write contract tests for that. Once again, I use only basic logic there: if A claims to be able to do c(d, e, f) with outcomes x, y, and z, then when B implements A, it must be able to do c(d, e, f) with outcomes x, y, and z (and possibly other non-destructive outcomes).
I simply kept applying these points over and over again until I stopped needing tests. Along the way, I found a problem and fixed it before it left my hands.
If I can describe the steps well enough for others to follow – and I posit I’ve just done that here – then I don’t agree to labeling it “magic”.
When I remove duplication from the siblings in a class hierarchy, I extract some code out to collaborators and pull some code up into the superclass. This often results in a kind of degenerate class hierarchy where the subclasses only override methods that return values or constants. They look like this:
class FindAllUsersRequest extends GetRequest { public FindAllUsersRequest(parameters) { super(parameters); } public URL getRequestUrl() { return URL.create("http://www.jbrains.ca/users/all"); }} Here we could replace class FindAllUsersRequest with a method on a GetRequestFactory—an instance where I find a factory appropriate.
class GetRequestFactory { static GetRequest findAllUsers(parameters) { return new GetRequest(requestUrl: URL.create("http://www.jbrains.ca/users/all"), parameters); }}In this case, we go from a class hierarchy with high duplication in the methods to a class hierarchy with duplication in which methods they override and that they override them to return simple values we could store (and memoize!). From here, we remove the subclasses, as they don’t pull their weight.
So the next you refactor a class hierarchy, watch to see whether your hierarchy wants to become a degenerate one like the example here. If so, I recommend you consider collapsing it.
I realize that I’ve never really written this down before, and I say it so frequently in my work as a trainer and mentor, that I think it bears repeating.
I have reduced everything I’ve ever learned about effective object-oriented design to the four elements of simple design that I first learned from Kent Beck’s work. Maybe you can, too.
I define simple design this way. A design is simple to the extent that it:
Note that I put these properties in priority order. I’m willing to copy-and-paste to get a test passing, but once the test passes, I can usually remove the duplication quickly. I’m willing to extract code into a method and call it foo() in order to get rid of duplicate code, although that name foo() rarely survives more than 15 minutes. Finally, I will gladly introduce interfaces, classes, methods and variables to clarify the intent of a piece of code, although generally speaking once I make things more clear, I can find things to cut.
Some people put “minimize duplication” and “maximize clarity” in a tie for second place. I don’t. My experience has led me to conclude that removing duplication helps more than fixing bad names does. Moreover, removing duplication tends to allow a suitable structure to emerge, whereas bad names highlight an inappropriate distribution of responsibilities. I use this observation as a key element of my demonstration, “Architecture Without Trying”.
Now I should point out that, as a test-driven development (and now also a behavior-driven development) practitioner, I write tests as I draw breath, so I don’t really need to emphasize that part.
I should also point out that I’ve yet to see a codebase with low duplication and high clarity that, nonetheless, had considerably more design elements than it needed, so I don’t really need to emphasize that part, either.
That leaves me with two key elements of simple design: remove duplication and fix bad names. When I remove duplication, I tend to see an appropriate structure emerge, and when I fix bad names, I tend to see responsibilities slide into appropriate parts of the design.
I claim these to be axioms of modular design, with a “parallel postulate” of whether you use objects or not. If you use objects, you get object-oriented design, and if you don’t, you get structured design. (I don’t know how functional design fits into this yet, because I haven’t done enough of it.)
I claim that developing strong skills of detecting duplication, removing duplication, identifying naming problems, and fixing naming problems equates to learning everything ever written about object-oriented design.
Put more simply, if you master removing duplication and fixing bad names, then I claim you master object-oriented design.
Now I wouldn’t bother burning your old OOD/OOP books, but I will tell you that if you have an interested buyer, then feel free to sell them.