VSTS Testing: Using Fiddler to record VSTS web tests

Buck Hodges

Sean Lumley, a developer on the VSTS web test team, has written a series of posts on using a new version of Fiddler to record web tests.  Sean worked with Eric Lawrence, who developed Fiddler, to incorporate new features that make this process much easier than in the past.  If you do any web testing, you’ll want to check this out.

Here’s a high-level description from Ed Glas, who leads the VSTS web test team.  By the way, check out Ed’s list of web and load test improvements for Orcas to see what’s coming in the next release.

We have released to web a new version of fiddler with a great new set of features around saving web tests. It is available at http://www.fiddler2.com/fiddler2/.

Credit to Sean Lumley for delivering these features, and thanks Eric for this cool tool that we could add onto.

Fiddler already had the ability to record AJAX and javascript popups, but it didn’t fixup the tests like the web test recorder does.

Now, fiddler will apply a bunch of fixups to the generated web test:

1) ASP.NET viewstate and event validation correlation

2) Dependent request filtering

3) Redirect filtering

Furthermore, Eric has added HTTPS support, so fiddler2 can record over HTTPS!

Even more exciting (to me at least, being the geek I am), is the new extensibility hook we provide in the web test save code. The features above (modulo the redirect filtering) were done using a new API we’ve provided. Like web test plugins, fiddler web test save plugins enable you to hook the save code to modify the resulting web test by changing or deleting requests.

The most powerful thing this enables is for you to write a plugin that will automatically correlate dynamic variables for a given application type. For example, an SSRS plugin would fix up the web test to automatically extract and bind the sessionid querystring parameter.

First, Sean goes into the details of the new features in Fiddler.

Enhanced web test support in Fiddler

If you have ever had trouble recording a web site with the web recorder included in VSTS, then we have probably suggested recording the same site with fiddler and looking for requests that the VSTS recorder did not capture. If you are not familiar with Fiddler, here is a short description from the fiddler site, “Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and “fiddle” with incoming or outgoing data.” The author of fiddler included the ability to save a fiddler recording session to a VSTS .webtest file. Although the file saved was a valid web test, there were a few problems.

1. The saved test included all dependent requests such as images, css file, js files, etc.

2. It included requests that were the results of a redirect.

3. The test did not correlate any hidden fields for you. i.e. viewstate

So although you could save a test, it was not saved the same way the VSTS recorder would save it.

I have been working with the owner of Fiddler to add enhanced web test support and he just recently released the updated version of fiddler to the web. You can get the updated version at http://www.fiddler2.com/fiddler2/. Here is a list of the new features:

· Ability to filter out dependent requests

· Only first request in a redirect chain will be saved.

· Automatic correlation of view state and event validation fields

· Plug-in architecture that allows you to write your own custom code that can change how a web test is saved.

I will discuss the last point in detail in a later post. I will walk through the other changes below.


Then he shows you how to write a web test plugin for Fiddler.

Writing Fiddler Web Test Plugins

My last blog post discussed changes made to fiddler which added enhanced support for saving web tests. This post will go into more detail about the changes and show you how to write your own custom code which can modify the way a web test is saved.

The main change we made for saving web tests was adding a plug-in architecture which is very similar to Web Test Plug-ins and Web Test Request plug-ins. The new architecture provides you with a hook into the web test save code so that you can modify what is written to the web test. Each of the new filter type features listed in my previous post were written by writing FiddlerWebTest plug-ins. For example, the FilterByExtension plugin loops through each request that would be written to the web test and flags certain requests to not be written based on certain extensions.

Let’s walk through the process of writing a new plugin. We will write a plugin which will automatically correlate dynamic fields associated with a SQL Server Reporting services site. This is the same reporting site I blogged about in this post: Debugging a Web Test. There are 2 dynamic fields which always need to be correlated for the reporting site that I am testing. They are the ExecutionID and the ControlID. By correlated, I mean that we need to the following:

1. Add an extraction rule to the first request to pull out the values for these fields for the current session

2. Then each time a subsequent request uses these parameters, bind them to the values extracted in the first step.


Finally, he’s posted a simpler web test plugin to help you get going.

Another Fiddler Plugin Example

Here is another example of a fiddler plugin.  This plugin will loop through each request and mark a request to not be written to the web test if it ends in a particular extension.  This example shows you how to flag requests to not be written to the web test by setting the WriteToWebTest property on the Session object.  Please see my previous post for how to deploy the plugin: Writing Fiddler Web Test Plugins



tags: , , , , ,


Leave a comment

Feedback usabilla icon