Following the previous exploration of writing the React component for unit testing at —-, I began to explore how we could ensure that the landing page we were playing performed high-quality product iterations. To get a taste of our business, we’re currently serving advertisers with a variety of landing pages on a daily basis, so we wanted to be able to quickly validate old features as we released new ones. In order to achieve this goal, we can ask the test students to regression the features that may be involved in this modification to ensure the normal function.

  • Solution 1: If you had to validate every time the code was merged with the master, it would probably be boring to test students because there would be a lot of repetitive work
  • Solution 2: However, if only the master code to be released is verified, once a problem occurs, the impact of the specific merge cannot be determined immediately, so the problem cannot be fixed quickly.

It seems that neither of the above solutions is the best, we want to automate the machine to help us back to the existing functionality, therefore, our automated testing was born.

First, let’s think about what features in our business need to come back

  1. Style UI we provide advertisers with a powerful custom UI style function, can quickly help advertisers to create a beautiful landing page, so we must hope that the past UI will not be affected

  2. The style button interacts and, after being clicked, conforms to expectations

Solve problem one: style UI problem

How can we let the machine know that this component is rendered properly?



The snapshot

Based on this, we have introduced the screenshot function of Puppeteer. After our code merge enters the master and triggers our CI process, puppeteer is called to take a screenshot of the most complete component function page we have created and compare it with the last saved image. Seems to realize here, there is no problem, there is serverless what matter, is it the title party rub heat?

However, we will find that the docker environment in which we call CI execution needs to pull the docker image created by ourselves, which needs to contain puppeteer and some basic libraries. Therefore, the process of pulling the image itself takes more time than executing our test case. Is there any way to shorten the time?

This is where Serverless comes in!

Serverless can be thought of as a function running on the cloud, which is triggered by an event, then an instance of the function is created, and finally destroyed. We just need to write the code for the function itself.

As we continued to refine our testing process, our ci build on the player side was reduced to a piece of code like this

curl http://serverless.example.com
Copy the code

We only need to trigger the Serverless cloud function, and then puppeteer crawles the test case page. After the screenshots, we save the generated pictures on Tencent cos and send the test report by email. The entire automated test can be completed in only 3s, greatly reducing the previous execution time. At this point, we have completed the first step of the UI snapshot function. But throughout the automation process, there are areas that can be continuously optimized

  • How can a machine tell itself if two images are the same?
  • Incomplete click interaction tests