Ok, now that we all know the ins and outs of making the Android Emulator and Charles play nice, let’s take a look at what we can actually do with it.
It’s my extreme pleasure to introduce you to Map Local. Map Local is a stunning little utility that Charles provides that allows you to redirect a remote API your app is calling to return, as the response, the contents of a file located on your local machine. Instead of actually pinging the URL of the API and returning the response as usual, Charles will intercept the request and return… well, whatever you tell it to return. But before we talk about how to do this, let’s talk about why you might want to.
In agile software development, often the back-end APIs that drive products are being developed at the same time as the front-ends. This presents an interesting challenge to front-end devs: how do you develop UIs to display data when there’s data to display? With Charles, as soon as the API contract is defined, devs can create stub responses, and use Charles to point their apps at those stubs. That way, front-end development can proceed alongside the back-end services.
Everyone loves a demo, but sometimes the thing your demo’ing doesn’t have any live data to support it. This is often the case with edge and error case demos. Creating test accounts for every edge-case variant can be tedious, and a lot of times, isn’t even possible. Using Charles allows you to create edge-case or error responses on the fly and demo how your app recovers.
Edge/Error Case Testing
With RESTful account-based applications, edge cases can be difficult to test. You can develop unit tests and manufacture the data with mocks and integration tests to exercise the UI, but developers can use Charles for end-to-end testing of edge and error cases during development and then turn mocked responses over to manual testers for validation. In addition, sometimes errors occur in the field but can’t be reproduced in the lab. In these cases, if a customer service rep can obtain actual customer data, it can be locally mapped into a dev-build of an app so that the problem can be debugged using the data that caused it to manifest in the first place.
Now that you understand why you might want to mock responses, let’s look at how to do it. In the last article I showed you how to set up an Android device or emulator to use Charles as a web proxy. Now let’s replace a live response with a mocked one. First go through your application until one of your API calls shows up in Charles. You might see something like this:
If you right click on the call in the left pane, and click
Save Response you can save the JSON to a text file, and then open and modify it a bit:
Now go back to Charles and right click on the
helloworld response again, and this time select
Map Local from the context menu. You’ll get this:
Now, in the
Local path field, enter the path for your json, or choose it from the finder. Click ok, and refresh your app:
Notice that this time, your local response is being delivered to your app instead of the actual remote response. You can use this tool to change any parameters of your payload to emulate any use case.
Another pretty handy tool in Charles is Map Remote. This is setup the exact same way in Charles, but instead of redirecting to a file, you can redirect to a different remote resource. This can be especially useful for inducing http error responses. Go back through the
Map Local instructions, but this time select
Map Remote, and you’ll get this:
Now go to my favorite http response codes website, httpstat.us, and grab the url to an http 404 response. Just paste the whole url into the
Host: field in the
Map Local dialog, and then click into one of the other text boxes, and Charles will automatically parse it for you into protocol, host and path. Click
OK, and refresh your app again (and if you mapped the url locally, make sure to go to
Map Local to turn that off…):
Notice that, this time, instead of hitting the
helloworld endpoint or local json file, Charles redirected the call to httpstat, and it returned the 404.
There’s lots more you can do with Charles, but I hope this has at least given you a glimpse of what’s possible. Next time, we’ll go a bit further by setting up our very own Mock Webserver…