Use Fiddler to live test JavaScript changes to your web site
Tags: javascript, fiddler, testing, webdev
Published: 2019-12-18 04:53:47

> Note: I originally published this article on Medium on 12/3/2019

There are time when I want to quickly test changes to JavaScript code running on a live web site, but going through a full publish process is too slow or cumbersome. Some development platforms such as SharePoint can make it impossible to run a local instance and iterate on a development machine.

For these scenarios, I've found that using [Fiddler](https://www.telerik.com/fiddler) to serve local file content in place of a live script is a quick, easy solution. Here's how I set it up using the Lutron web site as an example. I chose Lutron because, like the situation I found myself in, they use SharePoint for their public web site.

Load up the site in your browser of choice and hit F12 to see the content scripts. Lutron has a file called sp.init.js that looks like a good candidate.

![sp.init.js in the source tree](https://thepracticaldev.s3.amazonaws.com/i/6rcy0p0kb8ajfzi4ta99.JPG)

Like most sites these days, the Lutron site is serving a minimized version of this file, so we'll format it using the pretty print button

![Pretty print button](https://thepracticaldev.s3.amazonaws.com/i/6v0xi2ks3ysk8nw8v3w1.JPG)

And then save a copy off to the hard drive

![Save a copy of the formatted script file](https://thepracticaldev.s3.amazonaws.com/i/72okmiqvmkrkyttq79ho.JPG)

Before moving on, let's disable the browser cache so that a request for the file is sent with every page refresh.

![Disable cache option](https://thepracticaldev.s3.amazonaws.com/i/c976evth6zh4obhm9f1k.JPG)

Now load up Fiddler and refresh the page. Fiddler acts as a proxy and captures all the requests being sent to the server. Note that you will need to [enable SSL capture in Fiddler](https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS) if the traffic is encrypted. After the page loads, search (control+F) for 'init' in Fiddler to highlight the request. Click on the appropriate line to select it.

![Searching for init. We want the second one.](https://thepracticaldev.s3.amazonaws.com/i/0kj9y52e1xrlzvedobj1.JPG)

Now click the AutoResponder tab and the Add Rule button. The current request Url is copied into the Rule Editor.

![New rule](https://thepracticaldev.s3.amazonaws.com/i/j7lwoxh8e4q8z8mfvj5r.JPG)

As you can see, I've provided the local path to the file I saved earlier (which doesn't need to have a matching file name). I've also checked the boxes for **Enable rules** and **Unmatched requests passthrough**. By default Fiddler opts for an exact match, but in this case there is a cache buster on the Url, so I will remove that part of the Url and the EXACT specifier, and then click the Save button to update my rule.

![Remove EXACT rule](https://thepracticaldev.s3.amazonaws.com/i/cayyt35k14es4s8t6kpd.JPG)

There are a number of [rule matching options for AutoResponder](https://docs.telerik.com/fiddler/knowledgebase/autoresponder) should you require them.

Now I'll edit the code and begin my iterative testing.

![Adding an alert](https://thepracticaldev.s3.amazonaws.com/i/x9biftxj915egp5lt5jc.JPG)

With Fiddler enabled and the browser cache disabled a refresh will serve my local file instead of the one from the Lutron site.

![Hello world popup](https://thepracticaldev.s3.amazonaws.com/i/eqnu53qvvvylizbicb1b.JPG)

This technique can also be used to test changes to other web site content, such as HTML and CSS.