- To overcome the expense of creating functional tests it makes sense to have a good test recorder, which takes away most of the pain of creating tests.
- Tests can be brittle, so you should have some kind of functional test playback feature than automatically adapts the bahavior of the playback engine to overcome inconsequential changes in the pages tested.
- To split out tests of individual features you need some kind of CallScript capability that lets you organize your tests easily into groups of related functionality.
Interesting post, and yes we certainly agree that AJAX web applications can be quite difficult to test. But the picture you seem to paint is rather bleak, and it need not be.
The situation for testing an AJAX application is actually easier than you may think, provide that you have the right tools and by using their underlying technology base can "do the right things" at the right time.
But you are dealing with AJAX -- and it seems that you left out the most important aspect of all: test synchronization. Tests of AJAX type applications scream out for playback synchronization -- but not by adding Waits or Delays or Sleeps that never work in practice. There has to be a way built into your playback engine to interact with the DOM of the page and sense when it is OK to continue playback.
We believe if you have the right facilities in the test engine the functional testing job for an AJAX application can produce very good results.
We hope that will get a good discussion going. And, meanwhile, we invite AJAX application testers to send us an example AJAX application that they'd like us to test with eValid.