Testing AJAX applications with Fiddler

Testing AJAX web applications is very difficult. Ajax relies mainly on requests to the server  ( and responses received from them). We can't test what is sent and received from the server. The way to solve these problems is to use HTTP Proxy.

A HTTP proxy is a small program which intercepts between the client requests and responses to and from the server. The browser sends a request and the HTTP proxy receives the request. It then sends the request to the server and when it is processed, the response is sent back to the HTTP proxy. It is then sent to the browser. In addition to the interception job, it also records the information transfer. Fiddler is one such HTTP proxy tool which is used for testing and debugging Ajax applications.

                              

Fiddler, a free tool is an HTTP proxy for WINInet, which is the Internet Communication library used by many desktop applications, including Internet Explorer. Once installed, Fiddler automatically begins intercepting HTTP traffic to and from your computer.

Download Fiddler

Configuring Fiddler

If you want to get fiddler to listen to the requests too, go to Tools > Options > Connection > Connection Settings and check "Manual Proxy Configuration", "Use the same proxy for all protocols" and enter 127.0.0.1 port 8888 and click OK.  Note that this will pose problems if you close Fiddler as your proxy is gone, to solve the problem change back to "direct connection to internet".

Using Fiddler

The Fiddler window has two main regions. The left region shows all the requests that were sent from the machine. Each request is represented in a line. The line includes the response status, the protocol used (usually HTTP), the host name, the URL, the caching type, the length of the response, and the content type.

The right region has three tabs which are Performance Statistics, which displays information relating to data transmission rates, including the number of bytes sent and received as well as the types of data received. The Session Inspector tab provides information about the request and the accompanying response. The Request Builder tab allows you to manually construct a request and observe its response.

Another main feature of Fiddler is it has the ability to set breakpoints for HTTP requests and responses. As the request breakpoint is set, the Session Inspector tab is filled with information about the request. We can change the request before it is sent to server. Similarly, before the response is sent back to browser, we can edit the response.

Ajax debugging with Fiddler

• Ensures that correct data is being sent to the server
• Ensures that the data is sent in correct format and contains correct data
• Checks whether correct response is received from server
• Setting breakpoints for the request and response helps in finding out the error easily

Once you've recorded a session in fiddler you can then select the requests you're interested in, right click them and save them as a Visual Studio Web Test. You now have an XML file with the .webtest extension, ready to be imported into Visual Studio. Web Tests are used for testing the applications in Visual Studio 2005. You can know more information from my previous post Web Tests with Visual Studio 2005

You can find the Fiddler demonstration videos at this link

Source Via [Wrox Article]

Web Tests in Visual Studio 2005

Visual Studio 2005 and the .NET Framework 2.0 has a set of tools and functionality that will help the application development needs of today's large scale applications. It introduced a brand new set of tools for web and load testing. A load test of a Web application might span multiple machines and simulate tens of thousands of users, but at its heart it is a collection of Web tests.

Visual Studio 2005 enables web testing and makes it easy for the developer without writing any code. A Web test simulates how an end user might interact with a Web application. Typically, you create Web test by recording HTTP requests using the Web Test Recorder in a browser session, but you can also build Web tests manually using the Web Test Editor.

Recording a Web Test

Create a new Web test in Visual Studio. The Web test launches Internet Explorer, activating the integrated Web Test Recorder. Test recorder is used to record the actions you perform while you browse a Web site. The Web Test Recorder does not capture traffic sent between the client and server. This type of tool is sometimes called proxy recorder.

See for more information on Web Tests

HTTP Testing Tool - WBox

WBox is a simple HTTP Testing Tool written in ANSI C which works on a POSIX system like Linux. Windows systems are not supported and compiles on a MacOS X system. It is a 20 Kb zip file which has code written in ANSI C. We can use it to perform many different tasks which include

• Benchmarking how much time it takes to generate content for your web application.
• Web server and web application stressing.
• Testing virtual domains configuration without the need to alter your local resolver.
• Check if your redirects are working correctly emitting the right HTTP code.
• Test if the HTTP compression is working and if it is actually serving pages faster.
• Use it as a configuration-less HTTP server to share files! (see the server mode documentation at the end of the Wbox tutorial in this page, but it's as simple as % wbox servermode webroot /tmp)

Download WBox version 2

There are two modes of usage, one is HTTP Client mode and the other is Server mode.

HTTP Client Mode

The way to use WBox is through command line. For example, an url

% wbox www.technogears.blogspot.com

works simply as a ping utility. We can limit the number of ping like requests by adding the number of requests as one parameter.

Timesplit Option

We can get the time information for different parts of the document using the Timesplit option.

Eg: %wbox www.digg.com timesplit 1

WBOX digg.com (64.191.203.30) port 80
0. 200 OK    44134 bytes    1326 ms 
       [0] 0-4095 -> 728 ms
       [1] 4096-8191 -> 254 ms
       [2] 8192-12287 -> 16 ms
       [3] 12288-16383 -> 17 ms
       [4] 16384-20479 -> 225 ms
       [5] 20480-24575 -> 12 ms
       [6] 24576-28671 -> 16 ms
       [7] 28672-32767 -> 18 ms
       [8] 32768-36863 -> 16 ms
       [9] 36864-40959 -> 16 ms
       [10] 40960-44133 -> 8 ms

Stressing servers and apps

We can make concurrent multiple requests using the clients number option parameter. Wbox will spawn the required number of processes, and every process will perform a query every second.

% wbox http://localhost clients 4
WBOX localhost (127.0.0.1) port 80
0. 200 OK    9939 bytes    14 ms
0. 200 OK    9939 bytes    22 ms
0. 200 OK    9939 bytes    26 ms
0. 200 OK    9939 bytes    31 ms
1. 200 OK    9939 bytes    4 ms
1. 200 OK    9939 bytes    7 ms
1. 200 OK    9939 bytes    7 ms
1. 200 OK    9939 bytes    4 ms
2. 200 OK    9939 bytes    4 ms
2. 200 OK    9939 bytes    6 ms
2. 200 OK    9939 bytes    10 ms
2. 200 OK    9939 bytes    3 ms
user terminated

Testing HTTP Compression

We can test a web server which acceps HTTP compression requests with the compr option. WBox includes the header to accept the gzip/deflate data encoding. It will be useful to compare the performance with and without compression.

HTTP Server Mode

WBox adds a feature of running a simple configuraitonless HTTP server. This is very useful in LAN or a network so that files can be easily shared. To start in server mode, you need to run

% wbox servermode webroot /tmp/shared

Try connecting http://localhost:8081. WBox uses 8081 port by default and can be changed using serverport portno option

Feel free to try this simple testing tool. It has the disadvantage of not being compatible with windows OS as many users use windows os's.

 

Download WBox version 2