Ian Bicking: the old part of his blog

Webapplicationacceptancetesting comment 000

True... I tend to use "acceptance testing" for everything that isn't "unit testing", but that's probably not very accurate. Functional testing or system testing is probably a better term. Though Grig pointed me to this: http://atomicobject.com/systir.page (a Ruby test system) which is really an acceptance test (specifying requirements at a fairly low but not obscenely low level), and that could fit into this model. It's not a comprehensive acceptance test, but it isn't too far off. Automated acceptance testing is possible -- FIT is an example of that sort of thing.

Selenium or Pamie are options for Javascript-run tests (from Grig's article). John Lee also put Javascript in his to-do for his stack (ClientForm, ClientCookie, Mechanize, etc); I think using Mozilla's interpreter or something. But who knows about that...

Generally I do manual Javascript testing, but that still leaves a place for automated tests. By avoiding dynamic Javascript and making sure your app degrades properly in the absence of Javascript, you can avoid regressions in your Javascript and make the application accessible to an automated testing tool.

Also, by doing this as a script you can avoid sensibility entirely -- you can jump to another page based on any calculation you choose, possibly derived from a regular expression-based parsing or whatever works. You aren't restricted to just following links and filling in forms that you can find on the page.

Comment on Re: Web application acceptance testing
by Ian Bicking