Regardless of the platforms Xtreme Labs works with, the majority of mobile applications will interact with servers through API calls. More often than not, these APIs are not designed in-house. They’re designed externally, and we are tasked with integrating them into our applications. Issues arise when API’s are delayed or do not function until release. APIs also may change after an application has been released. If developers are not informed of these changes before hand, this can lead to client-side crashes. In order to handle these situations, we developed a tool to simulate and stress-test APIs.
Our API simulator was created with the following functions:
- It can be used to simulate an API that doesn’t exist yet. Engineers can upload template XML/JSON files to return stubbed data which will assist in building their app.
- The simulator can intercept a real API response, and modify it before returning it to the user. It can be used to stress test your app to ensure it would not crash when it encounters: random symbols, changed field data types, delayed response, etc.
Suppose a developer wishes to test an API, and suppose the response they expect is as such:
{
"title": "API Simulator Blog Post",
"content": "This is a blog post"
}
Now suppose the developer wants to test the robustness of their client-side JSON processor. The API Simulator can be invoked with options that test poorly formed responses. For example, if you pass the params &random=true; the API simulator will randomly change fields of the JSON response with app-breaking strings, such as:
{
"title": "☃☃☃ ☃☃☃☃ ☃☃☃☃ ☃☃☃☃ ☃☃☃☃",
"content": "ݽݾݿءآأؤإئابةتثجحخدذرزسشصضطظعغػؼؽؾؿـفقكلمنهوىيًٌٍَُّْٕٖٜٟٓٔٗ٘ٙٚٛٝٞ٠١٢٣٤٥٦٧٨٩٪٫٬٭ٮٯٰٱٲٳٴٵٶٷٸٹٺٻټٽپٿڀځڂڃڄڅچڇڈډڊڋڌڍڎڏڐڑڒړڔڕږڗژڙښڛڜڝڞڟڠڡڢڣڤڥڦڧڨکڪګڬڭڮگ٩(-̮̮̃-̃)۶٩(●̮̮̃•̃)۶٩(͡๏̯͡๏)۶٩(-̮̮̃•̃).٩๏̯͡๏)۶ლʕಠᴥಠʔლ͔̙î̩́t̲͎̩̱͔́̋̀"
}
The API simulator can also randomly delete fields from the JSON response. In practical terms, an API probably won’t spit out a response like this. In reality, the most common “bad” responses are 404, 400, or 500 errors, where the server gives back an error. But the purpose of the API simulator should be clear by now — we are ensuring that the stability of the app does not depend on the behaviour of the server. In terms of user experience, crashes are completely unacceptable. Our apps need to be able to handle unexpected responses gracefully, which is why we’ve develop tools that try to break them.
About the Author
