Preventing Browser Timeout

Here are two approaches that framework developers can take to prevent browser timeout:

Polling

In this scheme, the initial invocation of the run script (e.g., "run.cgi") starts up the unit tests in the background, either by using a traditional fork/detach/exec method, or by passing along the request to run the tests, along with the desired output filename, to some compute server process. The run script then returns a page that contains an embeded "refresh" directive. This directive invokes a script that tests to see if the output file is available. If the file is available, it is returned to the browser. Otherwise, another refresh page is returned.

In effect, the browser is polling the server until the server has completed running the acceptance tests.

The end user sees a set of one or more "Running..." pages, and then they see the results.

The benefit of this scheme is that the user gets periodic feedback.

Heartbeats

In this scheme, the server arranges to send the browser a sequence of "hearbeat" messages (in the form of HTML comments) followed, eventually, by the output file. As long as the browser gets heartbeats, it won't time out.

To work this scheme, the run script forks, running the acceptance test in the child process. Meanwhile, the parent process enters a poll/sleep/keepalive loop, periodically emitting "<!-- running -->". When the parent detects that the child process has completed, the parent sends the output file to the browser. The leading HTML comments emitted as heartbeats don't affect page display.

The benefit of this scheme is relative simplicity. The downside is that users get no feedback while the tests run.

--DaveSmith