Turnkey Web Application Test Automation

Sometimes a web program under development comprises numerous dynamic forms with various texts and control objects.

Testing such a web application becomes a real nightmare since you should click on up to 1500 pages (approximately), test all functions.

And if there is more than one release, you should do this several times.

And one day you will realize that testing takes more time than development.

And e2e tests are on the horizon. But you still need to get to them and create test cases before starting creating them. Numerous test cases.

If the first two paragraphs have made you nervous and you have started worrying about the amount of future work, you will be really interested in reading this material.

This article will highlight methods of automated software testing when there will be no need to create numerous test cases or e2e tests with the help of a user.

Creation of proper automated test cases

Sometimes it may happen that the tests will be based on an external interface of software during web testing.

In such a case, you should verify that a user will see correct buttons, necessary titles, text blocks on a screen and that he/she will see an error message after entering personal information with invalid data.

Therefore, you need to record every step while creating a random test case:

1. Clicking on a button;
2.  Entering the necessary X value;
3.  Choosing the XX value from a drop-down menu.

Therefore, you should test:

1. If the XX text appears;
2.  If there is an error message;
3. If the Z title appears.

When you have analyzed the overall functionality of the web application you are currently testing, you can determine a certain number of unique tests and actions.

Only after this, you will realize that this can be easily automated.

Let’s start from the simplest.

Automation of event hooking

To properly track a process of interacting with controls such as buttons, switches, or checkboxes, you should always apply a click to an event.

Each framework has specific methods for these purposes. For example, frontEvent inside Angular and document.addEventListener in JavaScript and partly — in React.

For entry parameter control objects such as a calendar or an input, you should edit only a type of an event that must be subscribed by a user: you will have focusout instead of click.

fromEvent (this.elementRef.nativeElement, ‘click’)
.subscribe (tagName => {
if (tagName === ‘BUTTON’) {
this. testCaseService.addAction( `Click on a button “${action.name}”`
} else if (tagName ===’INPUT-CALENDAR’) {
this. testCaseService
.addAction`Choose a date “${action.name}” “${action.value}”`);
}
});

And the most important — tests. The way a web product must behave when a tester takes certain actions.

What should be always tested by a QA specialist? For example, he/she decides to enter an incorrect value in an input field, so a website should react properly to this action, displaying an error message.

Or, for example, a user clicks on a button and so a new screen is displayed, a title changes completely, some information appears, all navigation elements have changed their order in an unclear way.

All changes of such a type are more or less connected with the editing of objects in the Dom tree. There are numerous ways to track them.

For example, you can use MutationObserver in React and JavaScript or ngAfterViewInput in Angular (applying established directions to necessary elements of a web form).

ngAfterViewInit() {
const tagName = this.nativeElement .nodeName;
const text = this.nativeElement .textContent;
if ([‘SPAN’, ‘P’] .includes(tagName)) {
this. testCaseService.addContent(`**A text appears** “${text}”\n`);
} else if (tagName === ‘H1’) {
this. testCaseService.addContent(`**A title appears** “${text}”\n`);
} …
}

Automation of an e-2-e writing process

When we analyze a test case that is automatically generated, we can see that it is actually a common use case that is structured in some way.

Today there are numerous frameworks that have a unique gherkin notation that is based on various use cases: from SpecFlow, Cucumber.js to CodeceptJS and others.

For example, we can get such a test:

Feature: Automatically generated e2e test
Background:
When log in “login” “password”

Scenario:
When Click on the button “Someone else responds”
Then Switch to the screen “What relationship does someone have to the client”
And the title appears “Someone else responds”
When Choose in the field “What relationship does someone have to the client” “Relative”
When Choose in the field “Clarification” “A husband or a wife”
When Click on the button “Continue”

To make tests run properly, it’s not enough to use generated features, you should also create a processor for all established actions and validations.

And it’s great that you don’t need to create a processor for every feature.

And it’s unique advice since even if we have 1000 unique actions and therefore, tests, we will get the same number of first-class e2e tests.

Obviously, software code will differ due to direct dependence on a framework you choose and a website’s layout. The creation of such a processor won’t take a lot of time.

And here is an example of such a trick :

Conclusion

If you properly use automation tools even for the biggest and most complex projects, a process of creating flexible e2e tests will take up to 2 minutes. It’s 60 % faster than the manual creation of such tests.

Now it’s impossible to work only with e2e tests, using them as a unique test source. An age of various frameworks and other system solutions allows not only simplifying a process of test creation but also creating flexible techniques and methods of test automation that can be used for similar web functionality, even later.