forum.e-valid.com

How does eValid differ from systems that drive tests using JavaScript? What is the big advantage eValid claims?

32contin wrote:How does eValid differ from systems that drive tests using JavaScript? What is the big advantage eValid claims?

There are many reasons why evalid does not "drive tests using JavaScript" and some of them go back to the very beginnings of eValid.

A main goal of the eValid technology development was to provide a test bed or test driver that could work efficiently and easily with web browser enabled applications. In that beginning period -- going back to over 10 years ago -- we had completed internal "proof of concept" implementations of several kinds of testbeds. We tried out "wrappers," we tried out on-board programs using JavaScript passages, we tried out various "browser editors"...in short, we tried all of the combinations that we could think of.

What we discovered in our early engineering work was that there was a vast difference in the overall performance -- and a vast difference in how much each testbed trial solution interacted with the behavior of the web application. It was the potential for "bad interaction" which pointed the way for the team, because the underlying assumption was that, to be a good test driver, the test drive could not get in the way of the thing being tested.

Of all of the alternatives that were considered, we leaded strongly on the one prototype product that was built with an open-source browser. Having that kind of direct, immediate, "intimate" control of all of the signals and events and transfers and other activity while the browser gets the page components, assembles them into the internal document object model, and finally renders them to the user -- that level of interaction, we felt, was "perfect" for what we envisioned eValid to do.

We sill had to deal with the question of "overhead." No matter how efficiently you build a test driver, it is software so it takes some fraction of the CPU to execute. We settled on a target of not more than 0.1% interference with the application. And, the solution we ultimately chose, and which has become the eValid architecture, has met that goal in every regard.

So, the REAL reason that eValid does not use JavaScript to drive the test is that it is (a) too messy, (b) has too high an overhead, (c) imposes too large a footprint for the test engine, and (d) interfers with the normal operation of a web page. With the growing importance of AJAX this choice is more than justified -- eValid's architecture says "hands off" to the co-executing JavaScript passages that implement AJAX -- and this means that eValid tests are far more accurate and far more reliable than would have been any of the other architectures which we studied, and discarded as wanting.

eValid Support