Why testing Ext JS with Selenium and similar software is nearly impossible?

As I explained in previous note, automatic testing any application is possible provided one is able to write appropriate client, that will interact with the app’s interface in the same manner as regular user does. So… If my application is accessed through browser,  then Selenium will suffice, right? It can query DOM tree and invoke actions on found elements. after all. Well, that’s not enough when it comes to testing Ext JS apps.

Why is so? First of all, design issues (or features if you like). Ext JS is a library containing many various components to be used together. Developer writes applications entirely in JavaScript (or ext-js-javascript dialect, as my former colleague used to say), putting provided building blocks together. You need a prompt asking user to enter his e-mail address? Here you are – create a window with panel (container), text field and button for confirmation. In this case, at least four separate components are involved – Window, Panel, Button and TextField.  Working example here.

As one could already notice, developer writes no HTML at all. Framework itself cares about markup generation and components appearance uniformity in all supported browsers. But the problem is that resultant HTML is… terrible, at best. Just take a look and try guess what’s happening here:

…and it all for just a simple prompt! Querying such tag soup for interesting DOM element to interact with is next to impossible. Trying to do so will certainly give headache to any daredevil.

So what’s the alternative, beside throwing away Ext JS? Actually, solution is quite simple. It amounts to using builtin components selector and then firing desired events on them. For example, looking for the button from previous example and clicking it can be written down like this:

In this example I found and clicked button that has an attribute text with value Send.  Ext.ComponentQuery.query is very powerful. Although it resembles CSS selectors, ComponentQuery is poorer, but still sufficient for most cases. It brings whole thing to a higher abstraction level. Of course we still do queries, but not for DOM elements and attributes, only components. The query part looks as follows:

button is not an HTML tag name here. It is an xtype – “class” of component.

text=Send is not an innerText query of some kind. It only means text attribute of component equal to Send.

Similarly, we could query for the field expecting username  (xtype textfield)

This technique becomes even more powerful, when developers create their own components extending existing ones. Usually you would assign new xtypes yourself, which enables more precise queries.

So testing Ext JS doesn’t have to be a nightmare. It just requires understanding what is Ext JS made of and writing some glue code between testing tools and library itself.

Ext JS Pathfinder goals

  • Provide javascript library that will simplify interacting with as many components in Ext JS as possible
  • Support for Ext JS 4, 5 and 6
  • Seamless integration with other javascript testing libraries, especially those which can open browser window, for example webdriver.io