Common issues encountered when consuming API
There are some common issues that are faced by every Application Development Team when processing data received from an API. These issues seem trivial and often ignored during development and testing phases because the development team is focused on building a new feature or solving a business problem. Another challenge is that there is often not enough time and resources to thoroughly test the API integration.
So, what are these common problems that I am referring to? See the list below, it isn’t a complete list but should be enough to give you an idea:
- Receiving Null, Nil, None, Undefined values
- Receiving Empty Strings
- Receiving Less or More characters in a String or Character Sequence
- Receiving ‘0’ or negative numbers when a number greater than ‘0’ was expected
- Not receiving a required key/value pair
- Receiving ‘false’ or ‘true’ as the value when the opposite was expected
Each one of these issues can destabilize an Application if the Application isn’t written to handle them.
If the API response contains a small number of fields then most such problems can be caught and fixed before the software is released to the users. But as the number of fields in the API response increase, testing the impact of every unexpected value on the Application becomes prohibitively expensive.
Writing automated tests and integration tests coupled with mocking frameworks can be a way to uncover these problems. However, time must be allocated to write such tests. If the developers are spending the time in writing unit and integrations tests then the development of new features and other bug fixes have to wait. If a test automation engineers is tasked with writing automation tests for a feature then collaboration sessions have to take place between the automation developer and the feature developer.
It is also common to see that test automation and writing integration tests are the first few things to be ignored and put on the back burner when the project starts falling behind schedule. To speed-up product development and release, integration tests and test automation development tasks are de-prioritized to free up team members so that can start contributing to more immediate deliverables.
However, the Team is forced to return back to the issues again when the Application starts breaking down after the code is released and the users start using the Application. But there is a good chance that by now, the development team has already made commitments for next release.
Since we have seen this pattern repeat frequently, we started thinking what can be done to make it easy to test the impact of unexpected data on the Application being developed? Watch the video below to see our solution to this common problem before we continue the discussion
Here is what we tried demonstrating in the video above:
- We first created a Virtual REST API endpoint that responds to HTTP GET requests. A virtual API is an imitation of the real API that helps in creating test scenarios that can’t be always produced easily with a real API
- The virtual API then starts simulating different scenarios, automatically, without requiring any data modification
- Each time the virtual API is called, a different field in the response is set to an empty string or a null value. It also removes a different key/value pair from the response or reverses the value of the next boolean field in the response
We think that a solution such as the one we have built into our product could save valuable time because it doesn’t require going into the data-source and changing the data to create different scenarios.
Let us know what you think.
