Dependency Challenges

Objects often must collaborate with other objects in order to get their work done. An object tells another to do something or asks it for information. If an object A depends upon a collaborator object B in order to accomplish its work, A is dependent upon B.

An important part of building the Place Description Service involves calling an external API that takes a location and returns place data. I found an open, free Representational State Transfer (REST) service that returns the place data in JSON format, given a GET URL. This Nominatim Search Service is part of the Open MapQuest API.^[13][14]

Test-driving the Place Description Service presents a challenge—the dependency on the REST call is problematic for at least a few reasons.

• Making an actual HTTP call to invoke a REST service is very slow and will bog down your test run. (See ​Fast Tests, Slow Tests, Filters, and Suites​.)

• The service might not always be available.

• You can’t guarantee what results the call will return.

Why do these dependency concerns create testing challenges? First, a dependency on slow collaborators results in undesirably slow tests. Second, a dependency on a volatile service (either unavailable or returning different answers each time) results in intermittently failing tests.

The dependency concern of sheer existence can exist. What if you have no utility code that supports making an HTTP call? In a team environment, the job of designing and implementing an appropriate HTTP utility class might be on someone else’s plate. You don’t have the time to sit and wait for someone else to complete their work, and you don’t have the time to create an HTTP class yourself.

What if you are the person on the hook for building HTTP support? Maybe you’d like to first explore the design of the Place Description Service implementation overall and worry about the implementation details of an HTTP utility class later.