We recommend using Visual Studio 2017
This documentation is archived and is not being maintained.

About JavaScript and ActiveX Controls in Web Tests

In Microsoft Visual Studio 2005 Team Edition for Software Testers, you record your Web tests in the Web Test Recorder. You run your Web tests by using the Web Test Engine. The Web test engine works at the HTTP layer. The Web test engine uses standard HTTP request/response messages to communicate directly with the target Web server. It does not execute JavaScript.

This document will discuss how to handle JavaScript, ActiveX controls, pop-up windows, and AJAX in your Web Tests.


Usually, you will not have to add any special handling to your Web test for JavaScript in your Web application. While you record your Web test, JavaScript will run as expected, according to your Internet Explorer settings. Any values produced by JavaScript for use as form parameters or query string parameters will be captured by the Web test recorder. When you run your Web test with the Web test engine, the JavaScript will not run, but the parameter values set during recording will be used.

JavaScript Redirects

If your Web application uses a JavaScript redirect, by calling window.location, the Web test recorder might not capture the request. To fix this, finish recording your Web test and then manually add a new request. Set the URL of the new request to the JavaScript redirect URL.


Confirm that any validation or extraction rules are attached to the correct request.

JavaScript and the Web Test Viewer

You run your Web test by using the Web test engine, and view the results in the Web Test Viewer. The Web Test Viewer contains a tab that displays the HTTP response for each of the requests in your Web test. The HTTP response is the data of your Web test, that is, the data that tells you if your Web application is working correctly or not.


Validation and extraction rules that you add to your test are executed against the HTTP response.

The Web test viewer also contains a tab with an embedded browser control. The browser control attempts to display the HTTP response for each of the requests in your Web test. Because the Web test engine does not execute JavaScript, the embedded browser control is set not to run JavaScript.

Some Web sites contain a noscript tag in their HTML. This tag allows a Web site to specify an error message that a browser will display if the browser is set not to run JavaScript. If a Web site contains a noscript tag, you might see an error message, such as JavaScript required, in the Web test viewer when you run your test. The error message means that the page is not displaying correctly in the viewer, but most of the time the response will still be correct. You should examine the HTTP response to determine whether your Web test is working correctly.


You can also add validation rules to determine whether your Web test is working correctly.

JavaScript and Coded Web Tests

Some Web applications depend on JavaScript in ways that affect the HTTP requests. You can use coded a Web test to simulate the logic typically performed by JavaScript. For example, an application might use JavaScript to dynamically modify form parameters. In a coded Web test you can write code to make the same modifications to form parameters manually. For more information, see How to: Create a Coded Web Test.

ActiveX Controls

ActiveX controls in your Web application will fall into three categories, depending on how they work at the HTTP level.

  • Your ActiveX control is not doing any work at the HTTP level, and is just displaying something visual on the page. In this case, you will not have to add any special handling to your Web test.

  • Your ActiveX control is not doing any work at the HTTP level, but you want to test it. For example if you have a very large ActiveX control, you might want to test it in a load test to see whether it is affecting the speed of your Web application. In this case, add the ActiveX control as a dependent request to the page, and it will be downloaded during the test run.

  • Your ActiveX control is doing work at the HTTP level, for example retrieving data from a Web service. In this case, you must convert your test to a coded Web test and add the HTTP requests manually, or use the Fiddler tool that is described next.

The Fiddler Tool

Web applications that rely heavily on JavaScript, AJAX, ActiveX, or pop-up windows for their functionality can benefit from using the Fiddler tool for Web test recording. Fiddler works by acting as a proxy server, and can intercept and record all HTTP traffic. Fiddler is the best option when your Web test includes a large number of important requests that the Web test recorder is unable to capture. Fiddler is compatible with Visual Studio Team Edition for Testers and allows you to save recordings as Web test files that can be added to Visual Studio Team Edition for Testers projects.

The disadvantages of Fiddler are that it does not currently support SSL, it does not automatically track hidden fields, such as ViewState, and it does not filter out dependent requests.

Fiddler is available at http://www.fiddlertool.com. For more information about how to use Fiddler, see http://go.microsoft.com/fwlink/?linkid=56113.

See Also