Using Fiddler AutoResponder for quick service or response mocking

In my Testing  RESTful Web Services talk, I touch on service virtualization briefly, and I include a short demo of using Fiddler‘s AutoResponder. I’ve been meaning to look into other (free) tools but haven’t had the chance.

After a question on the Testers Slack, I realized I could do a short blog post on how I demo’d AutoResponder in my talk. It gives a quick idea of the tool and one way you could use it. I love Fiddler*, and there’s so much more you can do than what I’ve been able to use. Please don’t take this post as a “this is the only way you can do things” – I’ll be the first to admit that even though I’ve used Fiddler for years, I feel like there’s so much more to know about it!

*Note: I am not paid by Telerik/Progress for my endorsement; I just love the tool 😀

Why Fiddler?

If you haven’t used it, Fiddler is a web debugging proxy. It works like the Network tab of the Developer Tools in your browser, only it works for all network traffic (not just via the browser). You can set the proxy up so traffic from your phone flows through it as well.

It records network traffic, between your computer (or phone) and the Internet. That’s pretty much it. It can do a lot of things with that traffic, though. A LOT. And it’s free!

When I’m testing anything, really, I have it running. I’ve caught a few bugs just by happening to see that flash of red because a call to an API failed, or a resource couldn’t load. Not something a user would notice, and probably not a tester either if not for this tool.

Testing For Failure

Service Virtualization is vital for testing for failure, and removing dependencies on your testing (and development). You’re virtualizing a service, or making a mock. Some examples of when you would want to use service virtualization:

• You’re dependent on a 3rd party API
  • it’s not ready for you yet, so you need to mock the response it gives you to continue development
  • they’re not able to bring their service down for you to test the scenario of “what happens when our API gets a 500 error back from the 3rd party API?”
• You want to make sure no matter what, the end user has a good experience
  • testing unhappy path scenarios to make sure the site doesn’t crash
  • verifying your 500 or 404 pages as the user would stumble upon them
• You need to load test, but the vendor for the 3rd party API won’t let you load test their service
• You need to keep testing the look and feel of the website, but the service is down for some reason (maintenance, still under development, etc)

And I’m sure many more reasons are out there! Note that a tool like Fiddler will work if your website is calling APIs directly. If there’s some middleware that’s handling that, Fiddler won’t catch those calls. You’ll need to find another tool that your service hits directly.

Fiddler To The Rescue!

Ok let’s get to Fiddler (download Fiddler here!). If you haven’t used it before, it might be confusing. There’s a LOT there. The left section is the Session List (all of the requests made over the network), the right is where you understand or manipulate those requests and responses.

As you browse, as the websites you’re on make requests, the Session List will fill up (depending on if you’re capturing HTTPS). Clicking on one of the sessions will show you a plethora of information in the right pane. In the Inspectors tab, the top is everything about the Request, the bottom is the Response.

For example, I have a simple API that I wrote (just for practice creating a REST api in C#) that has a corresponding webpage. When I load the page, Fiddler does a GET call to my REST api in order to populate the page.

In the Session List you can see that the Result was a 200 (OK), and the URL that it effectively hit was /api/products.

On the right side, in the Request, you can see what the exact request was – GET /api/products. In the Response, on the bottom, you can see the Response Code was 200 OK, and then after the Headers, the JSON of the data that was returned from the GET call.

If I did the same call in Postman, it would look like this:

Mocking Responses

Now that we’ve got that baseline, we can mock a response. Let’s make the request for item 1 (the Rabid Bunny Slippers) return a 404 (Not Found) response. We don’t need to remove it from the code or the database, we just need to do a quick series of steps in Fiddler, and voila! Like magic!

I take my session from the Session List, drag it into the AutoResponder rules, then change the ruleset to a built-in one for 404. I click Save, enable the rules, then make my request again. You can see on the webpage it says “Error: Not Found”, and in Fiddler, the session shows up red, with a Result of 404.

Here’s a closer look at the rule I’m using here:

You can see under Rule Editor that I’m looking for an EXACT match to that request. If I make a request for product 2, I’ll get product 2 back without issue. I can change this using regular expressions and such.

For the response, you can find a file on your machine, or choose from the default options available.

Here’s the built-in 502 (Unreachable) response to loading all products:

I have a session of loading the page in my rules, then just set the response to 502. So when I reload the page, none of my products show up. A search for individual ones still works because obviously the server isn’t actually unreachable.

Here’s a closer look at the 502 rule:

And one more for funsies, here’s adding a delay to the results coming back:

I set the delay to 1000 (assuming that’s milliseconds). It’s kind of quick, but you can see on the webpage it takes a bit for the response to come back, and in Fiddler the session takes a bit to show the Result.

Here’s the delay rule close up:

I’ve used this with automation, actually. If there’s an element that sometimes is slow to load, I’ll put this delay on it and make sure my automation can handle it all the time. Or if I’m trying to test something that gets overtaken by another element, and I just need to slow it down a little bit.

Another part of responses you can change is pretty much ANYTHING. If you right-click on a session you’ve added to rules, and select Edit Response. Change the Response Headers, the Response Body (such as enabling elements on the page that you want to see, but the code keeps it hidden for some reason). Again, useful in automation but also any other kind of testing!

There’s So Much More!

There’s way more than I can (or want to) cover in a single blog post. I just wanted to throw together a quick post (that took a bit longer than I anticipated to put together!) about how I use AutoResponder. How have you used it? Anything I’m doing dreadfully wrong? Any tips or tricks you have learned? Please share in the comments!