eValid -- The Web Quality Suite
Browser-Based Client-Side Functional Testing and Validation
Page Timing/Tuning Transaction Monitoring.
WebSite Spidering & Analysis and Realistic Server Loading.
eValid -- Making a Script Invulnerable with Structural Testing
A typical scenario we often see is that you have a script that used to
used to work and then, suddenly it ceases working.
Clearly something changed, because a newly recorded version of the
same script on the application worked OK.
So, that's a true regression and the FAILure is a valid regression
But evidently there was no visible change in the application, only
some changes in the index values at which some page features were
located or possibly some value in a visible text field.
Re-recording the script re-established the index values and other
parameters and the new script worked.
Making An Existing Script "Invulnerable"
There is usuallya way with eValid to make a script that will in the future
be insensitive to that kind of a change...so that your test will
PASS by tolerating that location change.
Here is the outline of that passage of the script.
- Identify some fact about the spot in the application (using
PageMap to help) that will be invariant over time. Call that
spot the "fixpoint."
- Do an IndexFindElement to locate the current value of the index
on that fixpoint. That index -- which may vary as the
application changes/evolves -- will be the base for subsequent
- Move up or down from the fixpoint so you know you are paying
attention to the right page element -- the precise one that will
receive the click. That location will always be in the same
position relative to the fixpoint unless the page changes
- Force the target element to be in focus. This may include using
the IndexElementEvent command and possibly adding some Delay
- Now send the click event to that element, which you now know is
ready to receive the event, probably with an IndexElementClick
- Start a synchronization loop that waits for some fact from the
NEXT page, so that you don't get out of sync at some future
Such a passage now will be insensitive to the particular location of
that fixpoint, even when updates to the application move it around
What we can offer is to provide you with one sequence like what
is described above.
Once you have one of these passages set up it is easy to do more of
them because it is basically the same passage, with only the