In this paper, I will mainly combine the business practice and practice of nailing to describe the author’s understanding of the front-end automation test scenarios. At the end of the article, I also placed two articles that I think are written well, which can be used as a vertical extension of you, and this article will not describe in detail the good content that has been described in the extension article.

This paper will mainly from the “why front-end automated testing, front-end automated testing classification, business automated testing to grasp the core point, the core tool recommendation” these four parts to do the exposition, the following directly into the body.

First, why do front-end automated tests

In the stage of rapid business development, the flexibility and agility of front-end development play a decisive role. However, “agile” and “risk” coexist, how to “stable and fast”, we as the front-end technology should continue to explore the topic. With the continuous increase of nail volume, “quality first, stability above all” has become the current main body. In this context, the author has done a series of explorations and practices on “front end automation testing”. This paper will briefly describe some main concepts of “front end automation testing”. And behind each similar concept, the author’s thinking in the actual scene. Many people would say, front end as the business changes and iteration, the volatility of the code is very frequent, but ask yourself, your own hands, whether there are “two business” as the foundation of the team’s core business, part of the logic change little, this part as a core function at the same time, is all users can use, such as: the front landing pages, the front registration page, etc.

Especially for the high-frequency pages of these “core functions”, if bugs are perceived by users, the costs of “repair, review, public opinion and other influences” will become more and more uncontrollable with the development of business and the increase of volume. The following is a simple list of costs consumed in this regard:

  1. Fixing these bugs takes a lot of time, and we have to stop working on other things. A rough estimate is that each Bug will cost the developer at least 30 minutes, not counting the time it takes to fix them.
  2. All bug reports must be double-checked “by the developer himself or QA”.
  3. Opportunity cost: The development team must wait until bugs are fixed before continuing to develop or release as planned.
  4. Front-end bugs will directly affect user experience, leading to poor body sense of users, reducing users and even driving away potential customers in serious cases.
  5. Some code vulnerabilities, not through the black box or white box automated test coverage, it is difficult to reproduce and check these problems in a limited time, especially when modifying the previous code.
  6. Sometimes, the people who diagnose these bugs are not the people who developed them, which leads to developers spending more time because they are unfamiliar with the code.
The above 6 points, more or less in the project development, front-end development students will have a sense of body. Here is also a distribution chart of “Automated testing and cost statistics of Microsoft front and back end”. After reading the chart, we will further summarize and extract the positive improvement of automated testing on uncontrollable costs.

Figure 1-1(data statistical results of Microsoft’s test), the author mainly extracted three information:

1. 85% of defects occur in the coding stage.

2. The later the bug discovery stage, the higher the cost and expense.

3. The cost and expense of direct release without any automated test guarantee is very high.

At this point, there is a very clear preliminary conclusion as to why automated testing should be done. Finally, we will summarize why the front end should focus on automated testing.

Bugs in production often cost the company or organization many times more than bugs found during automated testing. Test Driven development (TDD) has an overwhelming advantage if the ROI is calculated as shown above.

At the same time, it is not difficult to find that an excellent technology-driven technology company, no matter front-end development, or back-end development, the core code function must be automated test driven development (TDD).

Now that we know why the front end does automated testing, let’s take a brief look at the categories of front end automated testing.

Two, front-end automation test classification

Front-end automation testing is generally divided into the following four categories: unit testing, integration testing, UI testing, and end-to-end (E2E) testing/functional testing. Although there are different scenarios, there are also advantages and disadvantages in “different stages”. It is important to emphasize the “phases” that will lead to different choices, because each type of automated testing itself has its own scenarios that are virtually irreplaceable.

**1. Unit test **

Unit testing: Refers to the examination and verification of the smallest testable units in an application, usually by independently testing a single function

Consider a scenario where you want to remodel an old front-end framework and develop a new backward compatible framework based on it. At this point, the old framework wrote sufficient single test cases for its internal API functions. So, when developing the new framework, run the single test cases of the old front-end framework directly, so that all test cases PASS (PASS), it can quickly ensure the consistency of internal API functions, and quickly verify all functional scenarios.

PS: In the opinion of the author, front-end unit test is a very effective automated test method that has lower cost and can cover more than 90% of front-end logic scenarios among all types of front-end automated tests.

2. Integration testing

Integration testing: testing how different modules (components) in an application integrate and work together. This, as its name suggests, is used to ensure proper collaboration between different components.

Consider a scenario where a test receives a specific POST request and the database adds the corresponding record. This is an integration test, not a unit test. The remote service and database that initiate post requests are completely different modules.

**3. UI test **

UI testing: Is the testing of graphical interactive interfaces. The UI layer is the entry point for the user to use the product, and all functionality is provided to the user through this layer.

For example: now you want to compare whether the “visual style of a particular page” strictly meets the “visual design produced by the designer”, which involves UI testing. Generally, it involves the comparison of UI snapshots (screenshot).

**4. End-to-end (E2E) testing **

End to End (E2E) testing/functional testing: Testing from the user’s point of view, treating our application as a black box to ensure that the entire application will perform as expected.

You don’t care about the internal implementation of the code, just open the browser, type the test case on the page, and see if you get what you want.

Unit tests, integration tests, UI tests, and E2E tests can be run separately at different stages of development to ensure overall application stability by isolating them from each other in accordance with the different stages before launch.

Three, business automation test to grasp the core point

**1. Integrate the operation of automated tests into the R&D process **

In a continuous integration process, testing typically occurs in the following three phases.

  • Unit tests are useful in the coding phase, where developers test their own logical code.
  • The middle stage of development is about being able to stop as soon as a problem is found. Integration testing, UI testing, and end-to-end testing are all available.
  • The production phase (before it officially impacts users) is primarily about running a subset of the functional test suite called “smoke testing” to ensure that there are no exceptions due to changes in dependencies and so on at deployment time.
A good automated test process must be integrated into the release process of the release platform. Must do, can restrain, can view, can control. Only in this way can we better ensure the continuous existence of use cases such as automated tests, as well as the long-term stability and readability of application code.

**2. Recommend business landing front-end unit test **

Referring to the front-end industry and “Microsoft’s Test statistics chart” in Figure 1-1 above, we can also draw the fourth conclusion: unit test has the highest input-output ratio in real scenarios among all automation test categories. In the actual nailing business landing process, this is also preliminary clear, so the priority is to recommend front-end business, ensure and complete the unit test cases and related suite capability support.

Below is a test pyramid in automated testing (agile guru Mike Cohn and later Martin Fowler developed the concept of test layering). The lower you go, the higher the rate of return, according to the test pyramid and the input-output ratio.

Figure 1-2 Automated test pyramid

**3. Treat front-end automated testing correctly **

As front end students, please do not have the following misunderstandings about unit testing:

  1. That’s what students do. As good developers, we are expected to ensure that our code is robust and forward extensible.
  2. Unit test code is redundant. Whether the overall function of the software system is normal or not is strongly related to the test of each unit component.
  3. Unit test code does not need to be maintained. A year and a half later, unit testing is almost obsolete.
  4. Unit tests are not dialectically related to online failures. Good unit testing minimizes online failures.
The single test itself must have the initial investment, whether this investment is worth, apart from the above statement, “do a wrong thing, far more than you do a hundred right things”, this sentence is worth bearing in mind.

For heavy traffic front-end services, single test must be added.

Many times the impact of one glitch is bigger and heavier than the impact of iterating through a hundred business requirements. In addition to reducing costs and improving efficiency — especially in code refactoring and forward optimization; Helping to find bugs in business front-end code is also recognized as an excellent tool in the industry.

4. Core tool recommendation

Below will be the corresponding tool recommendation according to the classification of front-end automation test. The recommendation only expresses the author’s personal suggestions and summary based on the investigation and scene practice of multiple teams in the industry. The corresponding official website documents and online user guide are relatively detailed. This article will not introduce the use of each tool in more detail. For details, you are advised to refer to the official website documents in the link below.

**1. Unit test: **

Jest is highly recommended. It’s based on Jasmine, with a lot of changes and features added, again out of the box, and good asynchronous testing support.

The Jest website address: [Getting Started] (https://jestjs.io/docs/en/getting-started)

**2. Integration test: **

No mainstream framework is recommended. For the integration test of small program, in-house developed test suite.

**3, UI test: **

(1) Needle. Website address: [Needle: Automated tests for visuals] (https://needle.readthedocs.io/en/latest/)

(2) backstopJS. Website address: [https://garris.github.io/BackstopJS/] (https://garris.github.io/BackstopJS/) 21

**4. End-to-end testing (E2E) : **

(1) The test of the Pure React project is well suited to Puppeteer. Official website: [https://pptr.dev/](https://pptr.dev/)

(2) Small program test: the end-to-end test suite needs to be developed internally.

(3) A cool end-to-end testing framework called Cypress. Website address: [https://www.cypress.io/how-it-works/] (https://www.cypress.io/how-it-works/)

V. Conclusion:

This paper mainly introduces the core concepts of front-end automation testing and the author’s thinking and understanding, and will elaborate on “how to do single test for business” in more detail.

At the beginning of nineteen nineteen, there were few good articles on the Internet, but this year, I gradually found many related articles in this field. You can feel this part of the front end, which is being explored and practiced by many teams. In the future, I will combine the practice in Dingding front-end team to extend the series of more automatic tests. Based on “quality first, stability above all”, explore the road of front-end automation test together from all aspects.

Technology focuses on communication and mutual learning. In order to write better articles, I have also read two articles related to the content, which can be used as your
Read more:
[https://juejin.cn/post/6844903983098626056](https://juejin.cn/post/6844903983098626056)
[https://juejin.cn/post/6844904047728656392](https://juejin.cn/post/6844904047728656392)