ExtJs and test automation

This blog talks about the automated testing of applications that employ the increasing popular ExtJs framework in their presentation layer. The tools that I have used previously (IBM Rational Functional Tester, BugBuster, TestComplete) don’t follow that particular trend and have pretty significant problems with the automated testing of ExtJs applications. I will briefly describe what those problems are, why ExtJs is resistant to automated testing and whether solutions exist to circumvent these difficulties.

The main problem with testing applications that employ ExtJs in their presentation layer is that the framework dynamically generates IDs for each HTML element. Why is this a problem? Because the tools for automated testing detect each element by their IDs, and if the page loading code for ID elements is different every time, the tool can no longer find that element.

Namely, at the creation of a test script, all the applied objects (for example, text input fields, links, buttons, drop-down menus) are saved together in an object map (the entire DOM tree of the object is saved). When the test is executed the tool runs through the script and searches for an object (for example, a “Confirm” button) for which it must execute an action. It first selects the desired object from the stored object map, then tries to find that that object on the page that is the subject of the test. In the event that the object is found, it is able to execute an action on that object (for example, pressing the “Confirm” button if it is found), but in the case that it is not found, most frequently the test terminates. In order to find the desired object, the tool passes through the entire DOM tree element hierarchy, and by definition detects the elements by their IDs. It is here that the issue arises – the ExtJs application will upon every page loading assign elements new generic IDs! When the objects are initially loaded into the map at the time of script creation, they are saved along with their current element ID values; it is virtually guaranteed that those values will be different than the values assigned to those same elements when the script is executed, preventing successful dynamic object identification. An additional problem arises in that ExtJs generates many parent elements, each of which contains its own dynamically generated element ID, so that when the tool searches for particular element, it must hunt through a forest of elements, none of whose IDs match with the expected one. The example shown in Figure 1 displays an object map and the amount of parent elements a single requested object has, while the dynamically generated IDs of all elements in the DOM hierarchy are also visible.

It is possible to partially circumvent this problem, but it usually necessitates a large amount of time and the results are frequently unsatisfactory. The basic method is to ignore all the dynamically generated IDs of the parent elements within the the DOM tree. This is achieved with the use of regular expressions (regex). It is necessary to manually go through the entire map of loaded objects and replace each generated ID with a corresponding regular expression, as shown in Figure 2.

The problem with this method is a great expense of time, since one object can frequently be subject to 20 parent elements, all of which must be manually edited, approaching absurdity. This method also slows down the execution of the test, since the tool must search through multiple branches of the DOM tree, many of which are unnecessary, and in some situations – if there is a large number of branches that are needlessly being examined – the object won’t even be found.

Naturally, the basic assumption for this method is that the object itself has a unique static ID. Even if we can/must ignore the assigned parent IDs, that is obviously impossible for the object we need to access (the “lowest” element in the DOM tree branch), since the tool would then be unable to find it. It is further problematic that frequent use of static IDs for object reference is considered bad practice in ExtJs and thus is facilitated through the use of itemID, whereas automated testing tools exclusively demand the ID field.

After everything mentioned above, we come to the conclusion that automated testing for applications employing ExtJs in their presentation layer is theoretically possible, but (currently) in practice is unprofitable and hardly feasible. The described method is slow, combersome, unreliable, unadaptive and consumes too much time.