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
