When I decided to write this paper, my intention was to raise awareness of the testability issue among API designers. But, I wouldn’t feel comfortable finishing it without talking about how we can move forward when API designers don’t do any of these things.
There is one simple answer: wrap it. I’ve visited a number of teams who have decided that it is just easier to wrap all APIs . If you decide to download some fancy database interface tool, you don’t use it directly from your code, you write adapters to which encapsulate it. Your adapters also become your stub points and you don’t have to rely upon your API vendor for anything with regard to testability.
This may seem like a lot of work, but often it doesn’t have to be. When you are wrapping, you have a wonderful opportunity to simplify an interface. If your API vendor gives you a class with 15 methods, write a wrapper that only exposes the two that you need. Or, better yet, look at the signatures of those methods and ask yourself whether there is some simpler way of presenting that functionality to the rest of your application. This wrapper that you write is under your control and you should definitely do things that make your work easier. Remember, API designers aren’t designing with your application in mind; they are designing code that they suspect will be useful across a broad range of applications. It would be mysterious if you couldn’t write a wrapper that is more suitable for your application.