ParaSoft's WebKing 2.0 Web testing software is a tool to assist developers in testing and deploying dynamic Web sites. It applies traditional C/C++ and Java testing techniques to the Web environment to identify a multitude of potential errors in a site. WebKing also provides a publishing mechanism to automate the testing and transfer of a site's components.

Installation
The installation process for WebKing is very simple. The package is available in both a trial and full version. The Java Runtime Environment is required (JDK2); WebKing is available with the JRE if the host machine isn't loaded with the JDK. For this review the installation was performed on Windows NT Workstation 4.0 with the JDK installed.

Working with Web Sites
To evaluate the deployment capabilities of WebKing, I developed a small Web site that manages a CD collection. The static pages provided basic site navigation options and the ability to add to the music collection. Each page was deliberately left with empty links and invalid tags for WebKing to discover. The pages that were devoted to modifying the collection also included JavaScript for managing and validating user input on the form.

To add the site to WebKing you must specify the source for the Web pages. Sites may be sourced via HTTP, FTP, Telnet, or a file location. Note: Specific testing features are available only if the site is sourced by an HTTP connection. In addition, the source code for the site's back-end applications are stored in separate directories away from the site content.

WebKing allows these files to be managed via indirect links, also established by an HTTP, FTP, Telnet, or local directory connection. By combining the site with indirect links, all the content from disparate sources can be managed as one site. Adding this site into WebKing was easy. Within a few seconds it was able to create the tree representation of the site's contents and the material housed in the indirect links.

To set up the publishing, indicate a target point for the content and apply pre- and postpublish commands and custom tests. The target for the evaluation is a local directory served by Apache. The prepublish command issues a Java compile on all back-end source code. Figure 1 shows WebKing's interface for creating publishing commands. All commands are required to receive command-line arguments. Once in place, WebKing automatically executes the compile commands and halts publication if the command fails.

The development process may be further monitored by the enforcement of coding standards. WebKing provides a graphical scripting utility, CodeWizard, that checks the source (HTML, stylesheets, and JavaScript) for errors and standards violations. Furthermore, common components that are designated to appear on all pages within a site may be coded in CodeWizard; the developer is notified if those components don't exist.

The total setup for publishing the site is relatively simple. The time taken to set up the process is well worth the time saved when updates to the site are required. As WebKing publishes the site, all tests are executed, and it completes the publishing operation only if all conditions pass. This allows the developer to identify and fix errors as soon as possible before release. In this case, WebKing caught all the errors in the site's static pages, stylesheet definitions, and JavaScript source code (intentional and otherwise), and identified the file and line number of the error. If the site is sourced from a local file, WebKing allows the developer to specify and launch an editor to make changes to the file in question.

WebKing's testing facilities provide the developer with a wide range of capabilities for putting a site through its paces. Testing functionality is encapsulated in four types of tests: white-box, black-box, Web-box, and regression.

White-box testing examines a site's construction by determining a path through the site, loading static pages, executing server-side programs with automatically generated inputs to retrieve dynamic pages, and loading the entire site into a tree view. It then accesses every page and checks links, HTML, JavaScript, and cascading stylesheet code for errors, and standards deviations. WebKing then executes server-side applications to expose exceptions and other errors.

As the music collection was put through white-box testing, WebKing continued to identify errors in the site's construction. The tests executed in the white-box test facility will continue to be executed as publishing progresses. One key feature of the procedure is the handling of forms. WebKing provides the capability to create customized form data, called a data set, and apply it as submitted data against a form (see Figure 2). This allows the developer to test the execution of back-end systems and the construction of the output pages. The data is treated as if a user had navigated the site; therefore, all back-end data stores are updated with the test data if applicable.

As a Web site evolves over time, regression testing is key to ensuring no new errors are generated by code modifications. WebKing performs regression testing by executing all previously saved test conditions. Built into the publishing process, regression testing is automatically executed every time a site is put through publishing.

Regression tests, as indicated above, were automatically executed as dynamic content was added to the music collection Web site. JSP pages and a servlet were added for dynamic display. The JSP pages are set up to behave differently based on the value of the attributes in their URLs. WebKing automatically generated an instance for each possible attribute value. Any errors in the construction of the JSP page are displayed in the same manner that static pages are displayed. In addition, if a wide collection of parameters is available to a JSP page, WebKing lets you select only the important ones in order to limit the number of page instances created and to allow the developer to focus on key content.

The output of the servlet was created as a page instance based on the data set of its related form. This page is also displayed in the same manner that static pages are displayed and shows any page errors the servlet may generate.

Web-box testing is WebKing's methodology for individually testing dynamic pages. It allows developers to test dynamic pages for their output as well as their source code. Web-box testing revolves heavily around the publishing process and provides a standardized process for developers to release content. Prior to publication, each individual page may be put through tests specific to that page. If any conditions fail, as with standard publishing, the publishing process is halted. Source code for any back-end program may be tested through add-ons to WebKing such as Jtest for Java. For the purposes of this review, only the output piece of Web-box testing was examined. The difference between straight publication and Web-box testing is the concept of critical paths, also seen in black-box testing.

Black-box testing allows the developer to test the functionality of a Web site. WebKing enables sites to be tested via a critical path through the site to ensure it flows and functions properly. Black-box also tests individual pages for elements that must be standardized throughout the site. For the critical path test, WebKing will generate a default set of paths through a site. The developer can then modify the paths and the inputs associated with individual pages, and set up loops and chains to test specific functionality.

To examine black-box testing, I use a larger site that's a combination of JSP pages and static HTML and already in a production environment. This site relies heavily on parameters passed between pages and a section of it is generated entirely from users' input. WebKing quickly generated the navigation paths through the Web site. To identify only a subset of functionality, specific data sets were entered and paths were either removed or identified to be skipped by WebKing. WebKing then executed all tests and documented the results in the same format as the white-box, regression, and Web-box testing functions.

As for the standardized components of the site, CodeWizard defines the specific patterns of code that make up the specific component. For example, if every page in a Web site will include a specific header, the CodeWizard may be used to define a rule to look for the header. Figure 3 is a snapshot of the CodeWizard and a sample rule. Each time a test session is run against a site, the CodeWizard tests may be executed.

Summary
With the ever-increasing complexity of dynamic Web sites, having a handle on the testing and deployment of site components is a key element to a successful implementation. The testing and deployment capabilities of ParaSoft's WebKing provide an effective solution for organizing, testing, and deploying site components. Its testing functionality allows developers to catch and correct errors and nonstandard code prior to deployment. The pre- and postpublishing commands provide developers with the tools to automate many of the tasks associated with compiling source code and moving files to the production environment. Overall, ParaSoft's WebKing is an easy-to-use and effective testing and publishing utility, and should be considered for the development environment.