Intent Driven Testing

Intent driven development

To summarize, IDD focuses on specifying the desired outcome rather than detailing how it should be accomplished. This approach emphasizes defining the goals, leaving the execution details to the underlying systems.

Take logging into an application as an instance. Numerous widely-recognized authentication methods exist, such as those provided by Google, Apple, Facebook, etc. In the context of IDD, the objective is to authenticate, and it’s up to the underlying system to select and manage the appropriate services to fulfill this intent.

Intent driven testing

In the realm of web application test automation, our approach to crafting tests often revolves around user interface interactions: clicking buttons, awaiting specific screens, entering data into fields, etc. Such tests can become cumbersome depending on their construction.

Consider, for instance, using XPath to pinpoint a control’s location. If the control is moved, the test fails, showcasing the fragility of this method.

Typical test scenarios involve navigating to the control: opening the screen, waiting for it to load, clicking the relevant tab to access the control, expanding its parent groupbox, scrolling to bring the control into view, and then entering the necessary data. Crafting tests this way is time-consuming.

Imagine a system that could streamline this process, requiring only the specification of desired inputs, like setting a specific value for a username. The system would then autonomously locate the input field, activate its tab if needed, expand any containing group, scroll the control into view, and input the specified data, simplifying the entire process.

Using the process api for testing

The process API supports module registration, offering significant flexibility to cater to specific requirements. You can develop a dedicated module for each aspect of the user interface. For instance, there could be a module designed specifically for interacting with the main menu. These modules possess inherent knowledge of the UI elements they are associated with, facilitating automation tasks.

Take a login screen as an example: you could design a login module that understands the process of system authentication. The only inputs required from you would be the username and password.

Moreover, if there are recurring patterns or components used across various applications, these modules can be reused to conduct tests on those applications as well, enhancing efficiency and consistency in testing.

Test case

Our application employs Selenium for UI automation testing, and I have developed a process API in Python that incorporates several Selenium actions. To enhance this, we integrate modules focused on business-specific functions into the process API. This API utilizes JSON to outline processes, which means even a straightforward operation like logging in can encompass multiple pages of intent definitions.

By incorporating a login module, the intricate steps involved in entering details, clicking the ‘next’ button, and waiting for the subsequent page in the wizard are condensed into a singular action within the process definition, streamlining the entire procedure.

{
    "type": "login",
    "action": "login",
    "args": {
        "username": "john",
        "password": "doe"
    }
}

Advantages

Test definitions become more streamlined, easier to understand, and thus simpler to maintain.
The process of creating tests is expedited since there’s less detail to specify. While there’s some initial effort needed to set up the systems, the long-term time savings due to reusability are substantial.
Designing your systems without relying on XPath enhances reliability, especially with UI modifications.
This approach allows the use of the same tests for various user profiles on a given screen, which not only saves time but also minimizes complexity.

Simply put: tests are reusable, faster to create, readable, maintainable and easy to define without getting bogged down with the details.

Summary

Define the intent instead of the implementation details.

caperaven