cvgs wrote:Hey eValid.
We keep hearing from your competition that you don't really need to run a browser to get full AJAX. That they can do it with a special engine that simulates AJAX with HTTP/S calls? What do you think?
Fair question, and the best answer we can give you is "it depends."
For one thing, we find that a lot of applications that claim they are AJAX really don't use the unique asynchronous push-pull type of client-browser interaction with the web server that characterizes "true AJAX." May sites that have extremely complex JavaScript (JScript) passages might look lilke AJAX, but because they don't have any possibility of de-synchronizing they don't really qualify as AJAX. Those can still be hard to test, but not as hard as an applicaton that really is AJAX.
And, yes, that simplified type of site, which is not really AJAX, can be tested with HTTP/S call modeling and simulation.
But the issue with AJAX is that the state of the browser becomes important, and as you may recall, HTTP/S is a "stateless" protocol. Ergo, if you have AJAX you can NOT test it with simple HTTP/S protocol exchanges.
An AJAX site has the capability of de-synchronizing a test playback -- usually if the recorded user wait times are not long enough for playback to stay coherent. (There are ALWAYS wait times that are "not long enough..." so this is really a pretty good test of whether your appliction is or isn't AJAX.)
To synchronize AJAX test playbacks needs an activity synchronziation process running somehow in the browser, and this is what eValid does with its family of SyncOnXXXX type commands. To do that kind of synchronization requires an active process -- these commands are built into eValid. To do this with HTTP/S is going to require that you write some kind of process that can check internal browser states to confirm an expected event has happened or an expected state has been arrived at.
That's hard to do at the pure HTTP/S protocol level -- unless you want to write you own browser to do it.
The eValid Team
