Unit Tests for Web Projects

I l @ ve RuBoard

Unit testing for Web projects is almost identical to that for software development because most programs run on the server side. The difference is that, in the customer server environment used in Web projects, many programs will require input from and output to a remote customer, whether a browser, a PDA, or a device not yet available. The communication between the server object and the customer will be via HTTP over TCP/IP, which is why we need unit tests for browsers.

Wanted: HTTP Unit Tests

One of the missing elements in Web XP is a suite of HTTP unit tests written in various languages. HTTPUnit requires tests to be written in Java, which is problematic because Java isn't the only language in which server-side components can be written. Visual Basic users will need help from Java programmers or will need to learn Java. That is why we have started an open source project on Sourceforge to create an HTTP unit test in Visual Basic. We encourage forming groups to create HTTP unit tests for all languages.

Unit tests can be written without HTTPUnit, but you will have to assume that the input from the customer is as you expected it to be. This is often necessary for programmers who are not working in Java.

Multiple Browsers

The most important nonfunctional requirement of any Web project is the browser you will support. Your unit tests are browser-independent, but the visual display of your site changes wildly from browser to browser and OS to OS. Even incrementally different versions of the same browser can behave in unpredictably different ways. In traditional software development, you code for one platform and when you are done you "port" the code to other platforms. In Web development you code for all platforms at the same time and all releases are to all platforms. This is the central problem of interface programming for the Web.

As we said before, Web projects can have teams of server-side programmers, interface programmers, project managers, graphic designers, copywriters, and customers.

Interface programming for the Web is a painful process. Assuming that programmers are using unit tests, testing how pages look and behave is the central job of your quality assurance people.

Server-Side Functionality Preferred

As a general rule you should keep as much functionality on the server as possible. Some years ago one of us created a shopping basket for a customer that required users to select the store at which they would pick up their purchases. We used JavaScript validation on the client side to ensure that they did this. Soon after launch customer service panicked because a number of orders had no store information. We figured out that many customers were using an old AOL browser that didn't support client-side JavaScript. Had we done server-side validation, this would not have happened .

The only part of the process that you have any real control over is the server, so you should take advantage of this when you can. Client-side validation makes sense for usability reasons, but your server code should not just assume that the customer's system is doing its job.

QA works from a "graphical style guide" and "storyboards" to determine if the Web site is displaying correctly and if the approved design has been used properly throughout the site. A number of tools on the market allow a single computer to view multiple browsers and versions. We use Vmware, which permits our QA workstations to connect to a Vmware server to toggle between multiple OSs and browsers. We do this because it is often not possible to run two versions of the same browser on one machine. Another, inexpensive way to do the same thing is to evenly distribute the range of browsers among your team and and have team members use a tool like VNC or PC Anywhere to test on each other's computers.

Choosing Browsers

What browsers should you support? The list of possibilities is endless, so we tell our customers to follow the 10 percent rule. Check the server logs from your existing site or use industry measurements, and support all browsers that are used by more than 10 percent of your users. Existing logs can tell you if your audience is different from the norm. For example, one of our customers publishes to the IT industry so usage of UNIX and Opera is significantly higher than overall browser usage averages.

I l @ ve RuBoard