Testing With Charles Proxy Part 3

In this series of blog posts, the goal is to help someone get started testing with Charles Proxy.

The series will cover:

Make sure to start with Testing with Charles Proxy Part 1, and Testing with Charles Proxy part 2 before going through this post.

In this post, we’ll focus on:

Bandwidth Throttling

What is Bandwidth Throttling?

“Bandwidth throttling is when your ISP (Internet Service Provider) deliberately slows down your internet.”

Source: NordVPN

This may happen if you have reached your monthly internet cap or you have forgotten to pay your internet bill.

Why do ISPs throttle your bandwidth?

According to NordVPN, here are the reasons why ISPs throttle your bandwidth:

As you can see, it is fairly common (or at least not unheard of) to have your bandwidth be throttled by your internet provider.

But what if you are testing and your ISP is not throttling your bandwidth AND you want to know what would happen to your users whose ISPs throttle their bandwidth?

Never fear.

Charles is here.

How to throttle your bandwidth with Charles Proxy (default setting)

Go to Proxy > Start Throttling

In the screenshot below you can see the difference in duration with and without throttling when loading the Contact Us page. (I went to the Contact Us page twice with throttling on, then on the 3rd request I had turned throttling off)

/rsz_throttlingdefault.png

Using the Throttling Settings screen

Go to Proxy > Throttle Settings

If you have throttling turned off, you’ll see a screen like this:

/rsz_throttlingsettings.png

You’ll notice when you change the Throttle preset, the other fields will update.

Test ideas using Charles where you trigger various error codes

It can be hard to test how the front end will render your site when various error codes are triggered.

Charles can be helpful here.

Let’s go over some common error codes and see how our test website handles them.

What we will be doing here, will be similar to what we learned in Part 2, with editing responses. We will edit the 200 response codes and change it to the error codes.

Note: You can also use error codes to edit requests, I just tend to use it for editing responses, so that’s what we will do here.

500 Internal Server Error

For this error we will focus on the Register screen, from the initial URL,) click on the “Register” hyperlink below the Login button (on the left hand side).

I have a breakpoint set up (see previous post for information on how to do this) that will be triggered when we get the response back from the server after sending the initial Register request.

Here is the information I submitted:

/rsz_1registerscreen1.png

Once the breakpoint is triggered for the response, this is what I see.

/rsz_1initialresponsescreen.png

I now switch to the edit response tab and change the 200 to a 500.

/rsz_2editresponsescreen.png

Here is how it looks afterwards in Charles.

/rsz_500responsepost.png

And here is how it’s rendered in the UI. (note that I forgot to take a screenshot the first time around, so ignore the username here).

Looks like some more testing is needed here!

/rsz_500ui.png

504 Gateway Timeout

Here is another example, this time we will be focussed on the Accounts Overview screen. We can access this screen once we are logged in.

Below we have changed the 200 to a 504.

/rsz_1504editresponse.png

Here is how it looks in Charles after the change.

/rsz_1504acctscharles.png

And here is how the UI renders this.

/rsz_1504accts.png

Moving forward

When it comes to knowing which error codes to test for, it helps to talk to the backend developers in your team to see which ones the frontend could get.

You can also have discussions with the team as a whole, to see which errors you are expected to support.

The above examples are just a starting point to give you an idea of how you can go about checking how various error codes would display.

Let me know how throttling bandwidth and trying out the error codes worked out for you - you can reach me on Twitter: @NicolaLindgren