^{Photo by Jim}

If all you have is a hammer, everything looks like a nail.

Every sprint, we have a team testing session with one hour fixed time slot. It’s a team-fun-thing for all team members to try out new features. I take the honor to organize this testing party. But unfortunately, the last sprint I failed to prepare test devices in time, which causes that the team testing didn’t end very well. I feel shame for it. I ask myself why it happened? After I think again and again, one thing I could tell is because of my bad use of a good tool.

A good tool

Undeniably, Charles is an excellent debugging proxy. It’s powerful and handy. With a clean UI and easy setup, it becomes my daily tool. I rely on it to inspect HTTP/HTTPS requests and response, set breakpoints, simulate response status, mock response, bandwidth throttling, etc…

Naturally, more I use it, more I like it; More I will use it, then I will like it more….

Bad use

One day, I tried rewrite tool in Charles to replace a simple JSON API response by some mock data. I found surprisingly that it worked very well. Since that, I started to add more and more rewriting rules for this and that… Nowadays the set of rewriting rules becomes really complex. The mock data I used to replace response which started from the beginning as 4 lines, until now the entire content of a 4K file!

Sometimes I complain “Why Charles gives users only 1-line input filed for replacing stuff. It’s not possible to edit long text. How bad design it is!” Now I think it again and I have to admit that Charles is not designed for that. I use it wrongly. I should use it as a simple match-replace function for some strings, that’s it.

Another mistake I made is to treat it as a proxy server. Usually, I connect 1 Android and 1 iOS device to Charles proxy. But the craziest time, like last team testing, I ran Charles with heavy mock data and planned to setup the connection of 10+ mobile devices. The connection was not stable at all. The half of devices were disconnected frequently.

As it’s named as “debugging proxy”, it’s unfair for it to support 10+ devices “debugging” at the same time.

Right tool for the job

Charles proxy is not a snake oil for manipulating http requests. It has its pros and cons. In my case, I need a proxy tool to mock response data heavily and to change mock data easily, meanwhile it should also provide stable connections of massive mobile devices for testing. Charles is a good tool for sure, but in this case, it’s not the right tool for my need.

I have to search for a proper solution. I find that mitmproxy could be a candidate to try out. Because of open-source and the support of customized python script, it would be flexible to adapt all kinds of situations. All I need to do is to make scripts to fulfill my need. I like making my hands dirty. Luckily, mitmproxy provides a good documentation and nice forums. At the end, it’s not too hard to write mitm-rewrite-script, which provides me the function I need.

Tools are designed to help us to deal with the problems. Depends on the different situations and the strength & weakness of tools, I have to think carefully and decide which one to use. Probably mitmproxy is my new proxy-hammer, but I won’t see everything like a nail. Once I decided that it is a good time to use Charles properly, I would say loudly and confidently “I choose you, Charles!”