It should be common knowledge that for certain types of automated tests, you do not want to rely on the availability of external services for a number of reasons:
- Uptime of said service (your tests fail if the service is unavailable)
- Dynamic nature of the data (makes your assertions harder)
- Execution speed of your tests
- Excess load generated on the service
Ideally, you therefore stub out the external service. Inside your unit tests, you do that using Mock Objects, for example. This is actually harder to do for integration tests – you do not use mock objects in integration tests, because that could change the observed behavior of your application.
In one of our projects, we’ve struggled with this problem for quite some time. There are two major components in it, an iPhone app and a server-side component, which both talk to an external webservice for retrieving the data to display on the app and to work with on the server. In our integration tests, we simply used the production webservice and ran some shallow assertions on the result with varying results.
Recently though, we drew the line. Running integration / UI tests using KIF for iOS on data that changes depending on what time it is ended up in unpredictable results, or assertions that we simply couldn’t make because the data kept changing (and of course because KIF does not have any actual assertions, or is able to match on partially matching UI elements). So we said “Okay, we need predictable results – make that damn fake webservice already.”
What it needed to do was:
- Return fixed, predictable results with specific, recognised requests
- Forward the request to the currently used live webservice, so our existing tests don’t all break
- (later) Add a feature to make the data returned variable, some tests rely on the test data returned to have dates that lie in the future
- Do not compromise the security – the live webservice requires HTTP authentication.
Of course, it also needed to be done quickly. We postponed making this fake webservice for a while because it seemed like a lot of work, but once we finally decided on making it, we figured “How hard can it be?”. We’ve been waiting for an opportunity to use NodeJS for a while now, and as far as we could see, this was the ideal choice in this case – we have a REST-like webservice (readonly) that mainly does i/o (from the filesystem and the external webservice), and it should be easy and lightweight to build.
So we went to hack in a few steps. Read more for the whole article and the code.