A friend of mine works for tigdb. At lunch today, he mentioned that he finds himself using external services more and more. It’s the path of the future! In yesteryear, you might have written your product’s source code all by yourself. Very early on, it became commonplace to borrow other peoples’ code, typically from libraries provided by the language’s author. These days maybe you incorporate entire third party libraries, or open-source projects. The next step in the chain is making calls directly to 3rd party services over the web.
So how does that work with test-driven development (TDD)? If you write functional tests around your use of the third party’s system, they will fail whenever the third party’s code fails. That makes them intermittent tests. You can’t have intermittent tests in your dev cycle.
First, realize that you are testing two different things:
- your code does the right thing given that their service works the way you think
- their service works the way you think
So write two different tests. One runs your code but without touching the third party service. You sub in a fake version of the third party’s service, which always returns a canned response. The canned respons has just enough information to let your code do its job.
The other test only tests the third party service, without running any of your production code, and asserts that the service does what you want. That test is an External Service Integration test. Separate it from your normal tests. Production code that your own engineers commit should never cause it to go red. Run your external service tests periodically, instead of as part of one of your development cycle. When one of those goes red, you contact the third party instead of fixing your code.