{"id":17986,"date":"2016-12-30T00:00:26","date_gmt":"2016-12-30T00:00:26","guid":{"rendered":"https:\/\/www.fullcontact.com\/?p=17986"},"modified":"2022-04-05T08:34:23","modified_gmt":"2022-04-05T14:34:23","slug":"chaos-testing-our-mobile-apps-at-fullcontact","status":"publish","type":"post","link":"https:\/\/www.fullcontact.com\/blog\/engineering\/chaos-testing-our-mobile-apps-at-fullcontact\/","title":{"rendered":"Chaos Testing our Mobile Apps at FullContact"},"content":{"rendered":"

Let’s have a bit of a straight talk \u2014 chances are your app isn\u2019t tested nearly as well as you\u2019d want it to be. And neither is ours. There are a lot of ways to get to this point and a lot of articles covering them so let\u2019s skip this part and focus on making the situation better instead.<\/p>\n

So how can we fix that? Well, the obvious answer is \u2014 slowly. When you make changes to some part of the codebase \u2014 write a test for them. Maybe introduce a new architecture pattern to make the code more testable (we are fans of Clean Architecture<\/a> ourselves).<\/p>\n

But in the meantime \u2014 your app is in production. It is complex. It doesn\u2019t wait. It sometimes fails for weird reasons. Networks are flakey. You have a bunch of interdependent network calls. HELP!<\/p>\n

Chaos Testing<\/h2>\n

Chaos testing<\/a> is basically causing systems to fail in a controlled manner to see how the failures impact your solution as a whole. The term was coined by the good folks at Netflix who’ve had great success testing the stability of their services using Chaos Monkey<\/a>. And while this has been applied very successfully with backend service testing, there hasn\u2019t been much talk around chaos testing mobile apps, except for the UI automation and testing tools like Application Exerciser Monkey<\/a> for Android or UI AutoMonkey<\/a> for iOS.<\/p>\n

Since our mobile apps here at FullContact<\/a> do a lot of network calls while synchronising your contacts, we rely heavily on chains of network requests to make sure that everything syncs nicely and without race conditions (RxJava and RxSwift<\/a> are VERY handy in that respect). So the question becomes \u2014 what happens when a network call in the middle of a request chain fails? Maybe it doesn\u2019t fail completely, just partially. Maybe it causes some unforeseen issues in a completely unrelated part of your app!<\/p>\n

The way we approached this ourselves was to gather our Android and iOS teams in the same room, change the API url\u2019s to another dev\u2019s computer, which was running our chaos testing tool Proxinius<\/a> on it, and then observe what happened when we purposely mess up an endpoint or two.<\/p>\n

\n
\n
\n
\n
<\/div>\n


\nProxinius is angry and will not let your requests pass!<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n

\n
\n
\n

Proxinius<\/a> is a Clojure REPL based proxy (it’s open-source, so go try it out!), which mutates the responses returned from our backend.<\/p>\n

There are two mutations available right now:<\/p>\n