How does AJAX work? In a non-AJAX Web application, a user event such as a button click generates an HTTP request to the Web server. HTTP requests are synchronous, meaning that the Web browser client program waits until the Web server returns the HTTP response. During this time, the user cannot interact with the browser -- any button clicks are ignored, which is often very annoying. AJAX uses a different mechanism. In an AJAX Web application, a user event generates a special XML-HTTP request. This is quite similar to an HTTP request except that an XML-HTTP request is asynchronous, meaning the request operates behind-the-scenes. This allows the user to keep interacting with the browser while the request is being processed by the Web server. When the XML-HTTP response is returned to the Web browser, the browser then updates the Web page. Additionally, when using AJAX, you can design your Web application so that only the part of the Web page which has changed (typically new data from the Web server) needs to be repainted. The result is that well-designed AJAX Web applications have dramatically improved performance compared to non-AJAX applications. AJAX only works with Web browsers which have full XML support. Currently this means Interne Explorer, Firefox, and Safari. But because AJAX is so popular, it shouldn't be too long before most Web clients can take advantage of AJAX. Next time, I'll describe testing AJAX Web applications.

AJAX (Asynchronous JavaScript And XML) is a technology which can be used to improve the performance of Web applications. AJAX is currently a very trendy technology -- by that I mean there are lots of new AJAX books, AJAX conferences, AJAX magazines articles, and so on. Technology is subject to trends just like anything else is. AJAX is not a programming language, it is a technique that uses existing languages in a new way. Before I explain how AJAX works, let me explain the problem that AJAX solves. Suppose you are at a Web page which displays maps, such as mapquest.com for example, and you click on a "North" icon to indicate you want to see the area to the north of the map section being currently displayed. Traditional (non-AJAX) Web technology would send an HTTP request to the mapquest.com Web server, then the server would find the map image you are requesting, then return that image to you, where your Internet Explorer Web browser would render the image. All of this would take quite some time (perhaps a second or two), which results in your Web page blanking out for a moment. AJAX is a way to solve this performance problem. Using a well-designed AJAX Web application, if you clicked on the "North" icon, you would get a very quick and smooth response to the next image. I'll explain some of the details next time.

In my last entry I described how software test engineers can write UI automation which calls Win32 API functions. Using this technique is powerful but somewhat difficult. So difficult in fact, that there are many companies which write libraries using the technique and sell the product as a commercial test framework. Examples include Mercury, Segue, ParaSoft, and Rational (part of IBM). These commercial test frameworks are very expensive. However, in a Microsoft .NET environment, there is an alternative approach to UI automation. Windows applications which are .NET applications (meaning created with C# or VB.NET and which run on a Windows machine) can be tested using a technique called reflection-based UI automation. "Reflection" is a term that means a set of .NET methods which testers can use to access almost all aspects of a Windows application, including the user interface. It turns out using this technique to write UI automation is significantly easier than calling Win32 API functions. The image below shows an example of reflection-based UI automation in action.

A fundamental way to test Windows application programs is called UI (user interface) testing. Here a tester exercises the application under test by using it just as a user would -- through the application's use interface. UI testing can be performed manually. The tester launches the application under test, enters some input into the system (typically by typing information into text box controls and clicking on buttons), visually examines what happens to the application, determines a pass/fail result, and records the result (typically in an Excel spreadsheet). Manual testing is absolutely necessary but tends to be very tedious and inefficient. Automated UI testing is more efficient, but ends to be quite difficult. The tester writes a program which simulates a user exercising the application by calling into the Win32 API. This is a set of DLLs that make up the actual Windows operating system, but which can also be accessed by programmers. The image below shows an example of an automated UI test run which uses this Win32 API calling technique.

A Windows application is a non-Web based program which runs on a user's machine. Microsoft Excel is a good example of a Windows application. In general you can identify Windows applications because they usually have menu items File, Edit, View, and so on. Except for very simple programs, Windows application programs are composed of building blocks called DLLs (dynamic link libraries). The most fundamental type of Windows application testing is the process of testing these building blocks. This is usually called unit testing, or API testing. The idea is quite simple. If the individual building blocks of a software system are not correct, the system as a whole cannot be correct. For example, suppose developers are creating a cribbage game program. Behind the scenes there is likely to be a DLL which calculates the point value of various card combinations. The image below shows an example of a test run which tests this DLL building block.