What tests would you include for geocoding integration?

What tests would you include for geocoding integration?

• A. Test only the local validation logic without invoking the external geocoding service.
• B. Mock geocoding responses, test success/failure, retry logic, rate limit handling, and storage of coordinates.
• C. Rely on manual testing by geographers interpreting address maps.
• D. Use unit tests that only check formatting of input addresses.

Answer: (B)

Testing geocoding integration focuses on how your system talks to the external geocoding service and how it deals with responses, errors, and limits. To make this robust, you want to simulate real API behavior in a controlled way rather than rely on real network calls every time.

That approach is best because it uses mocked geocoding responses to reproduce a range of scenarios: successful geocoding, API errors, timeouts, and rate limits. It also checks that your code correctly retries when appropriate and that the resulting coordinates are properly stored. Mocking keeps tests reliable and fast, free from network flakiness, while still validating the essential flows—calling the service, interpreting its results, handling failures, and persisting the output.

Relying on only local validation ignores the external service and its potential failures. Manual testing by geographers isn’t scalable or automated, so it isn’t suitable for regression testing or CI. Unit tests that focus solely on input formatting miss the critical integration behavior and data transformation into coordinates, as well as error and retry handling.