Cloudy weather has its problems

Back in the day (or in my case, way back in the day) , you developed a service, and (after hammering at it for a while) it worked. If you had to use an external API, it was one of the major ones (payment processors, major platform login tokens etc.). If one of them was down, then you and the users are probably too busy fighting away the rabid zombies to notice your application failing.

Today it seems that everything I handle is connected to a spiderweb of external APIs. Each service is an old timer cartoon evil boss – just sits in the high tech chair, and based on an array of CRT screens, and threatening phone calls, decides when to perform his only action – pressing a big red button. I have no issue with that. It’s cool that the service name can describe it’s entire function, and still fit on a single line with no scrolls. More so, it is way easier to test a service from A to Z, if there are no letter in the middle. It makes regression testing easy, so you can focus on the new and changed features. But…. it also means that in order to to test your little (yet chatty) service, you need to  make sure all of its little friends are online. Those little friends are also social beings, and cannot tell the time without several API calls of their own.

Wait, there’s more

So I worked hard, and managed to chase down all the external API providers, and made sure they support my testing environment. Some required specific IP address to be provided in advance. Done. Some payed APIs providers agreed to support limited amount of requests for free. OK….. have to keep an eye for that.

Cool right?

Let me list the issue I had with just a single one of my services:

  • One API always fails because the provider cannot support test data, not even the data they sent us in the past for this exact purpose.
  • One API provider charges per call. This one was tested once and then we used a workaround that was luckily available.
  • One API provider kept failing our calls, due to SSL issues, related to some constraints we had on the testing environment.
  • One (other) provider supplied us with a non HTTPS API, but their test environment goes down for a few minutes, every… well, few minutes.
  • All external APIs were blocked from time to time, as our IT experimented with new infrastructure that kept changing our IP, and the allowed outgoing traffic rules.
  • Oh yeah, it goes without saying that we cannot trust any of these APIs to support our load testing

Sounds like a headache, and it is.

 

We mock. We act.

So we can’t trust anyone else (which actually sits well with my QA oriented personality…), but changing your service in a way that circumvent the API calls means you are not testing the actual product that goes into production.

Time for some API mocking.

 

Some ground rules, and then some other rules

Before I get started, here are my constraints:

  • Only open source / free to use / something we already payed for products allowed.
  • Allowed learning time before presenting a working solution – up to three hours.
  • Mock service should be accessible by a simple configuration change on our service (that’s my addition to the bunch).

 

Sometimes you bang it with a rock

It would make a better story if all the mocks requested were complicated in a way that required a mega hack to complete. But, as with real life, there are some low hanging fruits. Some of the services I mocked in the past had some very elaborate responses, but the responses were constant. There was a little complication that the  mock had to return two different responses for the exact same request, one after the other. For manual tests, I used Fiddler’s AutoResponder. Nice and easy. Overall, I used Fiddler for three of the APIs I mocked. Then there was a third party web service that had a bunch of logic in it. I started to work on it using SoapUI (the open source version, according to the rules above). I’ve used SoapUI in the past for API testing, and trivial web service mocking, and found it a very fun product to play with (with some interesting limitations and flaws, or in other words, character). However, after digging around and learning the methods to insert logic to web service mocking, I decided to give it a pass. If I have to replicate a lot of code, I prefer to do it in an environment (and language) of my choice. Lucky for me, the developer that wrote the code that consumes this 3rd party API managed to spring up a mock web service very quickly.

 

API mocking is no longer a nice to have ability

A few years back, when I interviewed for my team, I added a mock related scenario. It was painfully simple. A 3rd party API replies a simple “OK” or “Not OK”, but on the test environment you only get one case. How do you test the other? It was a kind of a bonus question, and failed by most. Today, this scenario is unavoidable, and I recommend getting some API mocking experience, even if it is for you personal fun.