Nice explanation. I'll add that when you start testing objects together, that's another type of testing -- integration testing. For complex interactions, that can be important to test as well.
A further bit of complexity to the picture, is that, from the outside, you may have a single object, which from the inside, is a collaboration of objects. In fact, in a well-designed system, this will be true at many levels. Generally, unit testing will focus on the objects near the bottom of this hierarchy, and when the System Under Test is a collaboration, it won't be involved in its setup. But anything external that should be injected, should be injected as a mock object. I recommend that all such external dependencies by done through an interface, rather than a class. I have a mock-object package that I've been meaning to open-source for the past year; I just need to choose where to host it. It takes an interface, and automatically creates a mock object out of it. It uses various customizable rules for what to return from methods; it can create a whole universe of mock objects starting with one interface, if need be. Mock objects allow you to not just control the values within the injected dependency. They also allow you to monitor and report on the interactions with those mock objects, including values set, performance, etc. In fact, I have used mock objects as instrumentation proxies in production systems. My mock object package provides for partial implementation, as well -- you can provide an object that partially implements an interface, either as a step toward a complete implementation, or where the partial implementation is specific to a test. The mock object package then completes the interface. Anyway, the point I want to make is that mock objects actually add considerable power to your testing in a variety of ways. Breaking dependencies to allow testing in isolation is just part of it. If you make full use of them, it can considerably enhance and accelerate the development process, allowing you to create and publish objects to the rest of the team for integration much earlier, and to test the aspects your building immediately without having to wait for large pieces of the system to be completed. On Dec 15, 4:48 pm, "A. Elk" <[email protected]> wrote: > On Dec 15, 12:39 pm, Etienne <[email protected]> wrote: > Test-driven development and unit testing require a different and > sometimes orthogonal mindset to traditional OOP development > techniques. Sometimes you have to be strict with yourself. If you find > yourself wanting to control the interaction of two objects in order to > test them, then you have to mock one of them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
