preface
This article is the start of the front end automation test series, which will move from theory to practice and really lead you to learn how to use the front end automation framework and put it into practice in your business.
Watch the entire series without using automated testing tools to improve production efficiency, please come see me!
Next week, we will update how the front-end automated test will be combined with React, and how it will work in the React project. Welcome to like and comment more! Your praise is the biggest motivation for me to write!
Before the boiling point said that the Nuggets post only boutique text, read at least 3k, see this line.
Between you and me, there are benefits at the end of the article!
The front end, as a particular kind of GUI software, is notoriously difficult to automate. In a business with rapid iteration and large UI changes, automated testing is more likely to land on the ground 🐶.
Recently in the learning process, through a number of front end test automation related articles, most of them are talking about how to use the automated testing framework to test of front-end code, rarely explain why introduce automated testing, introduce what are the benefits of automated testing, which projects suitable for introduction of automated testing, but these are what we want to know the real.
For those of you who may not be familiar with automated testing, this article will cover the basic concepts and basic uses of automated testing.
Before you start, do some foreplay (it can be long, fast-forward if you don’t like it 🐶) :
Scenario reduction
Xiao Wang is the front end development of a big factory in China. Just a week before the presentation, the product manager gave us a request to add new features to the old project.
Xiao Wang opened the old project code, a look, a tight mind – to change the component has been as long as 800 lines, a quick glance, found that there is no comment. Xiao Wang cried, but the product manager asked to implement the new function within 3 days, so he had no choice but to write.
Xiao Wang was ready to start writing. After doing a technical analysis of the new function, he found that the coupling with the old code was very strong, so he began to read and modify the old code while writing.
The old code is smelly and long, xiao Wang found that there is a piece of code do not know why to do the input text processing, think it is a useless code, but also affect their own to add new functions, so Xiao Wang deleted this piece of code.
The new function was completed on schedule. After a simple manual self-test, Xiao Wang found no problem. So he sent an email for testing and waited for the feedback.
The test of the new function also passed smoothly. Xiao Wang released the new function online. He finished this week’s work and went home to enjoy the weekend.
Xiao Wang washed and went to bed early, suddenly in the middle of the night the boss called: Xiao Wang, quickly get up, a BUG, affected 1W + users, quickly get up to see what the problem!
Xiao Wang suddenly got up, took out the computer from the backpack, began to investigate the cause of the BUG, after a debug, found that it was his delete that old code caused the BUG!
Xiao Wang cried again, fixed the BUG, emergency release online.
“Next Monday on the report, today out of such a BUG, year-end bonus is certainly not, the general estimate also hanging. Writing case reports and copying them to big departments is humiliating.”
But if the company’s old project introduced automated testing, the story was different:
Scene inversion
Xiao Wang was ready to start writing. After doing a technical analysis of the new function, he found that the coupling with the old code was very strong, so he began to read and modify the old code while writing.
The front-end development of the old project wrote the code for unit tests and integration tests to keep the project running, and the maintenance colleagues in the README were required to run through the test cases after adding/modifying the code.
The old code is smelly and long, xiao Wang found that there is a piece of code do not know why to do the input text processing, think it is a useless code, but also affect their own to add new functions, so Xiao Wang deleted this piece of code.
After wang deleted the code and ran the TEST case, several dazzling red characters suddenly came into view — FAIL TO TEST
Looking at the test case description, Xiao Wang realized what the code did. So Wang refactored the code, added new features, and ran through the test cases — all green passes.
Wang breathed a sigh of relief and added test cases to his new features, tinkering to make the new test cases work.
Although Xiao Wang worked a little overtime writing test cases, he felt relaxed and secure.
Everything went well and Xiao Wang enjoyed a happy weekend.
Next week after the report, good mood, good condition, the boss appreciated. Excellent performance reviews, year-end bonuses and general reviews.
The above story is my YY, if there is a similar purely coincidental 🐶.
What is a test?
Testing is a way to verify, manually or otherwise, that software that has already been developed meets engineering expectations and potential problems such as user/developer losses.
Most of the time, the front-end code we write is either developed for manual self-testing or tested manually by a dedicated tester.
Manual testing is fine, of course, but with automated testing tools, you can locate problems more quickly and efficiently.
An automated test is actually running a piece of test code to verify that the object code meets some expectation.
Later in this article, the term “test” will refer exclusively to automated tests.
Why test?
The purpose of testing is to detect errors in time, improve code quality and development efficiency, and avoid the loss of buggy code when it is released online.
The benefit of test automation is timely feedback, which can greatly improve front-end development efficiency.
In our daily development process, do we often need to manually test whether certain operations or processes are working properly after the project is running? Do you often need to break points or use console.log to check if a function is executing?
These scenarios, in which we need to manually test whether the code executes as expected, can be replaced by scripts that automate tests.
Many of the existing mature automation test framework can simulate our manual operation completely, using a script automatically run test cases, usually only takes a few seconds can give accurate feedback, at the same time also can listen for the code change, automatically perform project changed code in the corresponding test cases, can greatly improve the efficiency of our development.
At a time of rapid business and staff turnover, writing automated test scripts is increasingly profitable. Developers no longer have to fear introducing regression bugs, and no longer have to fear giving code to someone else to maintain. With the constraints of test scripts, iteration/refactoring is easier.
What are the types of tests?
There are three types of front-end tests: Unit Test, Integration Test, and UI Test.
The proportions of the three tests are:
The reality is that most companies have an upside-down test pyramid, with manual UI testing being the most frequent and integration and unit testing being largely ignored.
Unit Tests
Unit tests are the easiest to implement: utility libraries shared by multiple components in your code, child components shared by multiple components, and so on.
In general, there must be unit tests in the common functions/components to ensure that the code works. Unit tests should also be the most numerous and covered in the project.
A function/component that can be unit-tested must be low-coupled, which ensures the quality of our code to some extent.
Integration Test
Integration testing is usually applied to functions/components that are highly coupled, functions/components that are twice encapsulated, functions/components that are composed of multiple functions/components, etc.
The purpose of integration testing is to test whether unit-tested modules work together. The combined code as a whole is exposed to the external interface and tested to see if the combined code works as expected.
Integration tests are security tests that can greatly enhance the confidence of developers. The integration test cases are designed properly and the tests are passed to greatly ensure that the product meets expectations.
UI Test
In the process of literature review, I found that many articles in China confuse UI Test and E2E Test as the same type of Test.
In fact, there is a slight difference between UI Test and E2E Test:
UI tests are only tests of the front end, they are not in the real back end environment, they are just running the front end in the real environment, the back end and the data should be Mock.
End-to-end Test (E2E Test) is to run the entire application in real environment, including the data needs to use real.
On the front end, UI tests are closer to our development process. In a development pattern that separates the front and back ends, front-end development often uses Mock servers and data. So we need to do UI tests after the development is basically complete.
UI testing is not yet highly automated, and most rely on manual testing.
Some Test automation tools have the ability to create snapshots, which can also help us automate UI tests to a certain extent.
Which projects are suitable for introducing automated testing?
Most of the articles on the market today don’t address this issue, but it’s actually one of the most interesting ones to think about!
There is a famous saying in chemistry:
Talk of toxicity aside from the dose is rogue.
Similarly, in front end automation, talking about the benefits and necessity of automated testing, regardless of the type of project, staffing, and lifecycle of software development, is playing hokey.
Personally, I prefer to write test code, and it is very comfortable to see all the test cases with green passes.
But I guess most developers feel that there are so many requirements, so urgent, that it is too difficult to meet them, and there is no time to write test code.
In reality, we often develop one-off code modules for activities that are simple and have a low likelihood of subsequent iterations, making it unnecessary to introduce test automation tools.
Suitable scenarios for introducing automated tests:
- Development and maintenance of common library classes
- Iteration/refactoring of medium – to long-term projects
- References to uncontrollable third-party dependencies
These scenarios require the introduction of automated tests to constrain existing code. This is especially true for mid – to long-term projects, where iteration/refactoring is difficult for human regression, making automated testing particularly important!
How to select test tools?
There are many popular testing tools out there, but there is one common problem: support for new features lags behind.
The framework for front – end testing is full of flowers.
- Unit tests include Mocha, Ava, Karma, Jest, Jasmine, etc.
- Integration Test and UI Test include ReactTestUtils, Test Render, Enzyme, React-testing-library, Vue-test-utils, etc.
Comparison of mainstream testing tools
| The framework | assertions | The simulation | The snapshot | Asynchronous test |
|---|---|---|---|---|
| Mocha | It is not supported by default and can be configured | It is not supported by default and can be configured | It is not supported by default and can be configured | friendly |
| Ava | The default support | This parameter is not supported and must be configured by a third party | The default support | friendly |
| Jasmine | The default support | The default support | The default support | Don’t friendly |
| Jest | The default support | The default support | The default support | friendly |
| Karma | This parameter is not supported and must be configured by a third party | This parameter is not supported and must be configured by a third party | This parameter is not supported and must be configured by a third party | This parameter is not supported and must be configured by a third party |
Mocha
- Mocha is the most ecological and widely used single test framework, but it requires more configuration to achieve its high scalability.
Ava
- Ava is a much lighter, more efficient and simpler single test framework, but it is not stable enough to overload the CPU when running too many files concurrently.
Jasmine
- Jasmine was the “oldest” single test framework, out of the box, but with weak support for asynchronous testing.
Jest
- Jest is based on Jasmine, with a lot of changes and features added, also out of the box, but with good asynchronous testing support.
Karma
- Karma can be tested in a real browser, has a powerful adapter, can be configured with other single test frameworks, and is usually used in conjunction with Mocha or Jasmine.
Each framework has its own advantages and disadvantages, there is no best framework, only the most suitable framework. Augular’s default testing framework is Karma + Jasmine, and React’s default testing framework is Jest.
Jest is recommended and used by various React apps. It is based on Jasmine and has been heavily modified to date to add a number of features, also out of the box, support for assertions, emulation, snapshots, etc. Create React App new projects will have Jest configured by default, so we can use it directly without much rework.
What testing ideas are used?
TDD: Test-driven Development
- TDD: Test-driven Development: TDD requires that you write the Test code before writing the code for a feature, and then write only the functional code that makes the Test pass, driving the Development through the tests
BDD: Behavior-driven Development
- BDD: Behavior-driven Development: BDD enables project members (even those who do not understand programming) to use natural language to describe the system functionality and business logic, and to automate the testing of the system according to these description steps
Jest basic syntax
Since React/Vue is widely used in development by Dacang, and Jest is the official recommended unit testing tool for React/Vue, we will briefly introduce the basic syntax of Jest in this article.
matcher
Number
String
Array & Iterable
Exception
Asynchronous code testing
Lifecycle hook
Lifecycle hooks are executed in the order of the Onion model.
Execution order
Test units/use cases are executed in a similar order to an asynchronous queue
Function the Mock
summary
This article introduced some of the basic concepts of front-end automation testing and the basic uses of the mainstream testing framework Jest.
I believe that after reading this article, you must have a certain understanding of front-end automation testing.
The next article will bring you the integration of Jest and React automation testing framework, so that you can really be implemented in React projects and improve production efficiency!
At the end of the article’s welfare
Recently saw some big factory autumn recruit early batch began, the overwhelming internal push code.
As everyone knows, even if there is an internal push code to send a resume, it is possible because the resume production is not in place, the interview does not know the skills and other reasons and big factory missed!
Pay attention to Hello FE, there is a very detailed series of big factory, are a summary of the experience of various big factory bosses!
The resources
-
Lin Jiyu: Front-end automation
-
Stefano Magni: Component vs (UI) Integration vs E2E Tests
-
A reflection on react unit testing
-
Meituan-dianping technical team: Best practices for testing the ordering front end
-
Jest official documentation