What should I do with UI automation

UI test automation is always so entanglements, test automation beginners introduction to always take it, but some of the veterans are mixed to its, or throw a layered automated tests that the classic "pyramid", to illustrate the UI test automation or less as well.
During the period, the most concern was the automation technology of UI/client: from Web application to mobile App, from testing to RPA (robot process automation), from framework development to application promotion.
This article to share why want to do the UI test automation, UI automation test framework design points, team cooperation method, the promotion of matters needing attention and the rest of the comments, the hope can give you bring ideological collision.

Do you want to do UI automation?
If an organization really focuses on software quality, UI automation testing is necessary.
There are several reasons for this:

1. Any automation tools are most effective in simple, mechanical, repetitive task scenarios, and UI testing is very consistent with this feature.
2. For many organizations, UI testing is the most labor-intensive part of the test team, and most of the full-time testers work on the UI test.
   "Workers need to be good at their work," and testers need automated tools to improve their daily productivity.
3. No matter how complex and important the background is, the user interface is still the front-end interface.
   In addition to the background logic, there are a lot of front-end script logic and styles, which can't prove the usability of the client by simply relying on the background interface/unit test.
4. Test automation is indeed to a layered (unit testing, interface testing, UI test), from the Angle of the testing team, very hope to have sufficient unit tests and interface testing to ensure the quality of the test version of the actual situation is often development team maintenance unit tests and interface test is very inadequate, even little.
   So any project someone took the hierarchical automation test tell me don't do the UI test automation, I will ask them to first put the interface test and unit test to show me, and then discusses the implementation of automated testing strategy with them.
   But from a practical point of view, why is there a lot of skepticism?
   After all, three words are "unstable"!
   The test environment is unstable, the software interface is unstable and the testing framework is unstable.
   In fact, as long as the appropriate process improvement and development team cooperate, these problems can be solved or obviously improved.
   Take the test environment as an example. In the pure manual testing phase, some project test environments can be stopped and updated at any time.
   This also has an impact on manual testing (work schedules are disrupted, test plans are disrupted), but can be tolerated.
   Automated testing requires a more disciplined approach to the test environment, at least not at any time, which requires necessary improvements in the development and testing process.
   However, when the software interface is unstable and the testing framework is unstable, the test environment is not stable and easy to solve.
   This is mainly involved with the development team's cooperation, testing framework design.

Work with development teams to improve the testability of the UI.
In the theory of hierarchical automated testing, it is relatively stable and easy to implement the unit test and interface test.
In addition to the underlying code the user needs change is relatively small, write automation cases to lower cost, it implied a rarely mentioned reasons: unit testing and the work area of the interface test is usually a development team, if I found a method or service interface design is not reasonable to write automation test cases difficulties, even if not directly correspond to a defect, they also often adjust, optimize code design to realize more and more specifications.
UI test automation need to develop team refers to is not, of course, do not allow the development team to modify the UI, refers to the main contract and keep good UI coding standards, timely correction not corresponding function defect, but the coding problems affecting the UI test automation, etc.
UI test automation "positioning page object" is the most critical step, below a specific example, suggest some part of the development team, with the simple, how important it is for test automation.
The above figure interface, for example, if the test script you want to use the context object text location method (shown below), in the test framework to solve how to accurate positioning according to the text to the back of the input domain/drop-down box.

In fact, as long as the development team adheres to the basic standards of HTML, the specification USES the Label Label and the for attribute (as shown below), and it becomes easy to implement the above effects in the test framework.
If you don't adhere to the basic UI code specification, each developer will write the front-end code at will, and the cost and difficulty of the UI automation test will be.
There are many design methods of the automated testing framework, and the core idea of the automatic test framework design that the author has been adhering to these years is to "match the development pattern".
Taking Web UI development as an example, there are two main types of patterns:
One is to use uniform UI class libraries.
The enterprise or project team USES a unified front-end UI component library for development, such as JQuery.
The second is to adopt a unified development framework.
Enterprises to adopt a unified development framework, including UI development tools (or even a UI model driven development), in the uniform UI library, on the basis of through the tool or model to ensure that the UI code standardization and consistency.
In this two modes due to a lot of the UI library, front end will resolve a lot of, dynamic, machine generated page source code, is no longer suitable for the traditional script recording and page object recognition approach to make the test script.
Corresponding to these two development modes, the author often adopts the automatic test framework design pattern is the UI component encapsulation mode.
PageObject model is most often used to test automation mode, but in the development of the library system based on the UI classes, too many page object, and a lot of tools to identify the page object is also becoming more inaccuracies and intelligence.
The so-called UI components encapsulation mode, refers to according to the development in the UI libraries provide UI component types (such as input, select, date, button, tree, grid, etc.) corresponding to provide the corresponding test automation control.
Will each type of UI control way of positioning and interaction logic are encapsulated into the corresponding test automation control, testers through simple DSL language can describe the testing process (shown below), the concrete execution of unified processing to the test framework.
Through this test framework design patterns, can decrease the difficulty and the script code scripting, improve the stability of object recognition and execution, the impact of the UI library change limits to the test framework, not to the spread of the test scripts.
Development framework docking mode.
When the enterprises adopt the unified development framework, especially through the tool to generate a lot of the UI code, we can know which code is written by the developer, which code is generated by the tools, what information is in the frame of the development of unified management.
Fully utilizing these resources can greatly improve the usability of the framework when designing the automated test framework.
As shown in the figure below, after the docking development framework, we can easily access the project complete menu structure (as the test case outline) and accurately identify the page object.
With a complete test case outline and page object, it is much easier to write test scripts.
In addition, when the future version of the project is upgraded, it is possible to identify the change of the page object and the test script that affects it, and then remind the tester to modify the script in batches.
Reducing the cost of the script execution during regression testing, but with repeated modifications and repeated regression validation.