I would like to tell you a short story of how Charles has helped me throughout my project. Mind you, in this story, Charles is the proxy application. It would have been impossible to test numerous new functionalities introduced in the mobile application my team was developing without Charles’ assistance.
In the case of standard modules, backend developers provided “extensions” for the testing team, which allowed us to simulate most common errors sent by the backend API. All we needed to do was to send JSON parameters for the selected request and user. I must admit it was an example of great cooperation between the test and development teams as it has made our work easier.
When a new service was created for a new feature, unfortunately the “extensions” could not work for it. Therefore, a question arose – how to simulate it without the developers’ help.
It was clear at that stage that we needed a proxy tool. The first and most obvious choice was Fiddler. It actually had the right features for our needs so we decided to try it. It turned out that it was useful when used on Windows, but not on OS X / Mac OS. It was problematic even to run it, not to mention doing any tests. An alternative was needed. Two options were found and taken into consideration: Burp Suite and Charles Proxy. Both worked fine on Mac OS, but the second one, Charles, has a more intuitive interface. Even for a newbie like me it was clear how to use it.
Setting proxy on mobile devices
Setting up HTTP proxy on a mobile phone (an iPhone or an Android device) was not difficult at all. In Wi-Fi settings I selected Proxy settings where I entered my computer IP and default port (8888, which can also be changed). All requests from my devices were recorded in Charles.
Finally, I could set breakpoint on received requests. There were two options available: modify requests and modify response. In most cases, it was enough to modify received response code from 200 OK to 500 Internal Server Error or 498 Invalid Token.
By using Breakpoints I was able to test if the app works properly when it receives error codes – it enabled me to test negative test cases.
Since it was really the beginning of this feature development, it worked fine on HTTP. As the feature development progressed, HTTPS was made available. As I discovered, it was not a problem for Charles since it allows for SSL proxying, as well.
Unfortunately, it was not such a piece of cake be to used. The mobile applications (both Android and iOS) have SSL pinning built in. It was impossible to proceed without the developers’ help. I added tasks to both teams to disable SSL pining for this service. The iOS team agreed to add a special option for debug builds to switch off the SSL pinning. The Android developers thought that it could be too dangerous and didn’t want to do it this way. In this situation, the only option was to take another approach. I found that Charles came to my assistance again. It was possible to add certificate to debug build.
Now, it was possible to check communication on both platforms.
In the next stage of the feature implementation, an access call was implemented as only a limited number of users were allowed to use it. The limit on the test environment was set up to 100 users. It enabled us to use it on all test accounts. The backend developers came up with a suggestion that it is possible to disable the access by following a strange procedure, which is, as follows: first to delete your user, next ask a backend developer to set the limit to 0, which meant that all new users won’t get access, then test this case. After the test, you had to ask the developer again to restore the previous limit. It may sound funny, but it was not such a great joke. In this case, Charles also came in handy. I could overcome this hurdle thanks to the possibility to edit the body response.
This new feature worked fine until the test server was moved to a different instance. Unexpectedly, while trying to use the application, a specific error code occurred. In this case, the application should try up to three times when checking the access to the service, but iOS application was doing it constantly. On the backend side, the problem was fixed quickly, but it had to be fixed in the mobile application too. The question was how to simulate it. The breakpoints usage would be annoying: set a breakpoint, stop on response, modify, send modified response, stop on response, modify, send modified response, and then again. As you can clearly see, it wasn’t an option to be considered. Luckily, Charles has yet another great option – Rewrite. It enabled me to return the error code for the selected call without manual modification.
What’s more, the breakpoints list we prepared once was exported so all the test team members could use it.
Charles also has a feature to limit the network connection, which is called Throttling. It can be set for selected hosts and for this very reason, it was a better choice than using Network Link Conditioner on my computer. I could use the Developer Option for that on iPhone, but I had no counterpart on Android devices.
From a time perspective I am convinced that it wouldn’t be possible to complete this part of Project without Charles.
Charles has more features than the ones described above. I used Map Local which I discovered later to replace response body instead of breakpoints. The application also allows you to compose API requests so it is not necessary to use Postman at the same time for single requests.
Thanks to Charles, mobile application testing became easier and many of error cases could be tested.
Charles Proxy: https://www.charlesproxy.com/buy/