|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.
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.
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.
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.
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|