An eValid forum post recently asked this question: "You say eValid runs "from the DOM" but I'm no sure what that means, exactly.
Can you explain?"
It is a good question, and the response was this:
eValid obtains most of effects by manipulating the Document Object Model (DOM) that is maintained inside the browser.The DOM is an internal structure that the user ordinarily does not see. It in a kind of "private loop" to create and maintain what you see on the browser face.
Entries in the DOM are called "DOM Elements" and they are numbered 0, 1, 2... in a thread that is updated with each change in the state of the browser, or "triggers," that are initiated by the user or by some external event.
eValid provides a way of looking into the tree using the PageMap feature, described in part with this page: DOM Support Architecture.
eValid was the pioneer in this approach, fielding a product using that technology as early as late 1999, based on internal prototype systems developed from beginning in 1997.
Manipulating the DOM for purposes of testing a web application was very effective, and eValid's lead was followed -- over the years -- by WATIR, Selenium, and finally WebDriver, which is now standard in all of the major commercial browser systems.
That is all well and good, but you may ask how did that approach actually come about? Below is a "short" explanation of the history involved.
The main idea of eValid was to re-purpose the DOM, a key element of the browser, to provide a capability for testing and quality assurance of web applications. We got his idea based on these factors, in the late 1990's:- Need based on extant development of CAPBAK/DOS, CAPBAK/Unix, and CAPBAK/X to apply o web applications.
- Frustration that every existing approach was fraught with failure.
- Impossibility of doing the job with conventional methods (including SR's own tools).
The team then knew that thinking "outside of the box" was going to be required. Previously every product approach that tried to automate web testing failed for one reason or another.
The MS-DOS solution for CAPBAK/MS-DOS, based on intercepting the Windows screen-event loop, was clumsy and complex and not terribly predictable.
The solution used in SR's CAPBAK/X product for XWindows based UNIX environments, was based on intercepting the traffic in the X-Windows protocol -- i.e. the communication between the client and the server. It worked very well, but the future of the XWindows system was in doubt, particularly after the introduction of the IE 4 browser in 1997.
We remember a Microsoft employee who at a trade show in 2000, upon having just seen a demonstration of eValid, asked: "have you guys really build a complete browser?" No, the answer was that What we did was to simply overloaded the IHTML object in the Microsoft library..."oh, sure, of course, he said..." Easy enough, once done.
What has happened after 1999/2000 in rough temporal sequence was:
- WATIR a Ruby-based solution that drove tests by compiling a wrapper that drove the IE browser through the COM interface. This works OK, but can't support more than a single instance of test playback -- there is only one COM/desktop interface per PC.
- Selenium, conceived by Jason Huggins in 2004, used the OLE interface in Windows to drive web tests.
- eValid's first patent was filed in preliminary form on 31 October 2000, in final form on 31 October 2001, and issued 12 June 2007 as US Patent 7,231,606. This was the first of what was ultimately to be a Portfolio of 10 US Patents covering many parts of the underlying eValid technology.
- WebDriver was an extension of Selenium done by Huggins and Simon Stewart, that solved a lot of problems that the classic Selenium had. It was introduced by Stewart at the Google Test Automation Conference (GCAC), 23 August 2007. Webdriver incorporated the same DOM-based test playback method that eValid introduced in late 1999.
With Google leading by incorporating WebDriver in versions of Chrome, the other browser suppliers (e.g. Microsoft, Firefox, etc.) soon all followed suit and incorporated the WebDriver idea as an option. After a decade of use, the Webdriver additions to browsers dominate.
