Is Synchronization Always Needed?

[george.p]

The eValid product looks pretty good for my need, which is to drive the heck out of an AJAX-built application...

But the work involved in setting up an eValid AJAX sync step looks pretty daunting...I mean, you have to know things about the application that, well,
maybe our developers don't want me to know about.

So my question is: In an AJAX app does EVERY step have to have that fancy kind of synchronization? Or what?

-George

[eValid]

Thanks for asking and it is a good question.

We'll assume here that you are talking about doing DOM synchronizations.

There are two ways to look at this kind of issue:

One is that you have to have a "perfect" test and therefore you have
to understand the AJAX application so well that you can engineer the
required synchronizations into your script -- before the fact and from
first principles.

The other view is to make a recording "from life" and then play it
back to see if it synchronizes and if not, where it fails to sync?

So if a test script for an AJAX application has 10 synchronization
points, in the first approach you have to create 10 separate DOM
synchronization, and that can be a lot of work.

But in the second approach, you just "fix what doesn't work",
and that at worst will be the same work, but at best might be just
one or two passages.

The way to do this then is this:

(1) Make your recording "from life", and it will have Waits
in it that reflect your user-imposed timings.

(2) Play it back with a wait time multiplier of 1.0 -- natural
recorded time -- and see if it syncs.

(3) Then, play it back again and again with smaller and
smaller wait time multipliers, 0.9, 0.8, 0.7...etc. until
it DOES break, that is, fail to sync.

(4) At that point, fix what's not working.

At the end of this if you have a script that does not fail to sync
you're done.

We like the pragmatic approach: fix what doesn't work.

That is ALWAYS less work than the other method.