How to Test Live Services with Fiddler AutoResponder

The AutoResponder feature has been updated and renamed to Rule Builder as of July 2021.

It’s always a challenge to test app features that go outside the scope of your local environment. In this post I’m going to talk about how we test our product automatic updates that use AWS (Amazon Web Services).

Simply put, our app will send a request to AWS and check if there is a new version of the product. If there is one, a specific behavior will activate locally, and an event will trigger on the local machine. What I as a QA engineer would like to test if these events trigger correctly.

Here lies the challenge though. It is not so easy for me to simulate the real life scenario - I’ll need to create a test environment for this service, an engineer will need to create a new build flavor of the product that is set to make requests to this new test environment, I’ll need to communicate with the Admin team in order to get permissions for our AWS account, and maybe few other things that will come up in the whole process. Or… I can avoid all that setup and make things a lot simpler and easier by using Fiddler instead.

Fiddler Classic is a free tool and one of its powerful features is the ability to capture specific requests and return custom tailored responses to the client issuing the requests. Basically, it can act as man in the middle and this is very useful for testing. The AutoResponder can mock external services and help with testing specific behaviors triggered by responses from external providers.

It’s also useful if you are in the development phase where your feature is ready for test, but the web service is still not Live. Are you going to wait for the devops guys to setup everything or you will use Fiddler Classic or Fiddler Everywhere to create a mock response and complete most of your testing?

I’ll show you an example of a real-life scenario and how I use the AutoResponder feature in my own testing. I’ll explain where the AutoResponder is in Fiddler, how to set it up and some of its useful options.

The AutoResponder tab is here:

You can manually add a request to match or import a set of recorded requests from a Fiddler archive. For the sake of the example I’m going to create a new rule. Setting up the rule is very simple. You just need to insert the request you need to intercept - in my case it is a request to AWS like this <https://telerik-teststudio.s3.amazonaws.com/TestStudioVersionManifest>:

The next step is to select what kind of response you want to get when Fiddler matches and intercepts this request. Here is where it gets interesting, as there is a lot of freedom in terms of what you can do depending on the situation. Editing the response, you can set specific errors like 202, 403, 502, etc. This is especially useful for negative test scenarios.

In my case I need this request to return a specific manifest JSON which tells the desktop app if there is a new version available for download. This is us testing a “check for update” feature after all:

It’s important to check “unmatched requests pass through,” as this will allow your normal requests to pass unobstructed through the Fiddler proxy:

This is mandatory for this example only. There are scenarios where you will probably need to stop all other requests from your machine and allow only the ones set in the AutoResponder.

Another interesting and useful option is to simulate Latency for the response request. This allows you to test how your app handles unexpected latency problems. Does it timeout gracefully? Does it recover as expected? Who knows? You will know if you test any outbound requests with the simulated Latency:

Easy Testing of Live Services with the Fiddler AutoResponder

In conclusion, the AutoResponder feature in Telerik Fiddler is very useful in cases where you need to mock a service, and then get a specific response during development by reaching an endpoint which is not ready for deployment on the Test/Live environments. It is also useful in negative testing scenarios or any tests where you need to simulate certain network conditions like slow network, random network errors and such.

If you have any feedback or comments, let us know in the comments below.