Determining specifics of your web page

Note This section provides a first theoretical overview, the next section shows a realistic example.

HTML is a very flexible language for describing the content of web pages. But unfortunately there are no real standards with regard to components which should be used to draw a button, a textfield or a table showing data. That's why nearly every toolkit implemented its own way for drawing such components. This fact means that the HTML structure (the so-called DOM tree) looks different for every toolkit or framework. In order to allow QF-Test to identify the components as buttons or data-tables we need some kind of dictionary. The dictionary should contain a translation for the properties of the created HTML components to the QF-Test vocabulary.

Due to that flexibility of HTML your first step should be to get a good understanding of how the toolkit used creates its components and of the specific attributes and properties of the HTML components generated. The next paragraphs and especially the next section show some steps how to get this understanding of your web-page.

Once you identified a certain property determining a specific business component you then should configure QF-Test to map it accordingly, using the CustomWebResolver interface. At the end of the day you will have taught QF-Test which HTML tag or attribute represents a button, which HTML property represents a data-table showing data and so on. From a QF-Test perspective you assign generic classes to HTML tags. The generic classes will then trigger the default mechanism of the component recognition and item resolution of QF-Test. The mechanism is the same as you are used to from any other engine. You can find more details about generic classes at chapter 55.

Inspecting the HTML code of a web page can be achieved by using the built-in development tools of your browser or extensions like FireBug.

Figure 45.1:  HTML code inspection in Firefox

In most cases the HTML attribute class is significant for component recognition and provides information about the business type of that component, e.g. whether the component acts as button or data-table. Other toolkits might set the id or any other attribute. Of course there are also toolkits around which use JavaScript methods a lot. For adapting QF-Test to those toolkits you need to implement many more resolver. However, we set the focus on the simple use-case here. For adapting QF-Test to advanced frameworks based on JavaScript methods please get in touch with our support.

We start with calling the procedure qfs.web.ajax.installCustomWebResolver from the standard library qfs.qft and fill in the required parameters.

As already mentioned, the class attribute provides the class information in most cases, so we take a look at this attribute first. Our goal now is to create a dictionary for QF-Test of the technical properties of your HTML web-page. The next section will show this in detail.

The second step therefore is to map those determinative values to generic classes of QF-Test via the parameter genericClasses, which is described in the next section.

Once we created such a dictionary, QF-Test will then record the business related components only. This will simplify the component tree recorded by QF-Test. In the figure below you can see such a simplification for the provided WebCarConfigurator demo.

A call to the procedure qfs.web.ajax.installCustomWebResolver will be added to your setup sequence by the Quickstart Wizard. You can find that call in the sequence Install CustomWebResolver. You can adapt or replace that call accordingly.

Current recording Simplified recording
Current recording Simplified recording
Figure 45.2:  Reduction of complexity for WebCarConfigurator demo