The base concept of XLT explained including but not limited to the action model

When you perform web-based application tests, the possible paths from page to page define the web page flow. The web page flow can be depicted as a directed graph with the vertices representing the web pages and the transitions representing the actions to get from one page to another. Typically, a test scenario covers a certain part of the page flow only, such as a specific path through the application.

XLT provides a programming paradigm that makes use of a three-level architecture (transactions, actions, and requests). These levels are illustrated in the following sections.

In addition, XLT by default tries to see every user as an independent browser or machine. There is no connection pooling or sharing in between users, because this does not happen in real life either, hence your network layer will see a more realistic stress level.


A transaction is the execution of exactly one test case or test scenario. To perform the scenario, the page flow is modeled in code. The test scenario is implemented as a test case which itself executes a sequence of one or more actions.


An action can be defined as one irreducible step within a test case. Thus, an action interacts with the current page and – as a result – loads the next page. The resulting page is associated with this action and becomes the current page for the next action in the test scenario. Generally, an action triggers one or more requests.


This level is equivalent to the HTTP request level used in web browsers or in any other application that relies on HTTP communication. You don’t have to deal with requests directly because they are automatically generated by the underlying HtmlUnit framework when you perform actions on HTML elements.


As you’re testing the functionality of applications or pieces of software, you have to check the correctness of all responses. It is strongly recommended that you handle all potential situations and use validations as often as possible. It’s better to have too many checks than too few! They can’t do any harm and will increase your confidence that your application works correctly. Thus, make sure you include as much validation as necessary to detect any abnormal behavior in the software being tested.


Each action should have a pre-validation section that checks whether or not all of the required data is available to interact with that page and allow the test to advance to the next one. From the end user’s point of view, you simply look for the information on the page that you need to continue your web experience, such as a form to fill in or a link to click. In case the required information can’t be found, an exception is thrown. If you run a load test, XLT will catch this exception and log all relevant information. This lets you evaluate the results after running the test and narrow down error conditions.


Post-validations work similarly to pre-validations. They are used to validate the result of the interaction and ensure that the data matches the expectations.


The following example illustrates a very simple scenario to help you understand the terminology. It is based on the demo application Posters. Imagine a typical user searching the shop for products. The user will possibly:

  • Open the shop’s home page,
  • Search for a keyword but without results,
  • Search for another keyword, this time with some results
  • Select one of the shown products and open the product detail page

In this example, the test scenario is modeled as test case TSearch. A single execution of this test case is a single transaction. OpenHomepage, Search and ViewProductDetails are the actions of this page flow to go from one page to the next. Validations after each page transition ensure you arrived on the right page with the right content.

Last modified March 4, 2022