Page 1 of 1

Question about AJAX

PostPosted: Tue Aug 18, 2015 11:23 am
by MarioAT
Hi.

There seems to be a LOT of dicsussion on your User Forum about keeping AJAX tests fully synchronized?

What's the fuss all about?

Why won't simple waits resolve any issues the playback fidelity?

Thanks

Re: Question about AJAX

PostPosted: Wed Aug 19, 2015 3:24 pm
by eValid
MarioAT wrote:Hi.

There seems to be a LOT of dicsussion on your User Forum about keeping AJAX tests fully synchronized?

What's the fuss all about?

Why won't simple waits resolve any issues the playback fidelity?

Thanks


Thanks for posting MarioAT.

You're right.

There IS a lot of discussion on our forum about synchronization issues, and there has been, in the past, quite a lot of discussion in the software testing community about this subject as well.

At this writing, however, that issue has mostly been settled in favor of assuring synchronization.

The issue boils down to this: If a test of an AJAX application doesn't run fast enough due to some external cause, the playback activity will lose coherence.

That is, it will de-synchronize.

In this case, the likely outcome will be that the test is ruined -- and the output data will be useless.

The most-common reason for loss of sync is that the server stack supporting the AJAX application runs slower, and constant wait-time delays in the test playback script will be "not long enough".

Our experience is that something like Murphy's law applies:

No matter how long you make your fixed-time waits to assure 100% synchronized playback, there waill ALWAYS be a time when that wait time is not long enough.

If it can fail, it will fail.

The settled solution is to synchronize playback so that any next step that depends on a server response that could take a variable amount of time is actively checked for arrival at a particular starting state, BEFORE the test proceeds to take actions to arrive at the next sync point.

It is a little bit more work to construct active synchronization in a test playback script, but the increase in confidence (that the test won't fail even when the server is VERY slow) is worth it as a payoff to the test's user -- that is, the consumer of the test result.

eValid has a range of synchronization options, summarized here:

http://www.e-valid.com/Products/Documen ... mmary.html

Here are the specific commands in eValid that support the most-powerful form of synchronization, based on examining DOM elements:

http://www.e-valid.com/Products/Documen ... n.dom.html

It is generally true that eValid test scripts are the most resilient (resistant to failures of all kinds) of any possible web browser tests.

-- eValid Support