Business requirements change rapidly, involve a lot of UI and interaction, and most business scenarios are exchanging and processing data with the backend. The above facts make testing a very headache in the front-end field, and it also becomes an excuse for not writing unit tests in the front-end.
When we are faced with an unfamiliar field or scenario, content that is simple and quick to implement makes it easier for us to take the first step. The purpose of this article is just that, so that you can complete the spike content of the unit test and transplant the relevant content into the project code within 20 minutes.
Why write tests?
It is good to write tests
Due to its own special attributes, the front-end business is not easy to write unit tests. I haven't written a test for such a long time, and I feel that there is nothing wrong with it. In addition, the business demand for each iteration is so large that business development alone is already exhausted. I have always held this concept before, so I have never written unit tests.
Note: If the tests mentioned later in the article do not indicate the prefix, they all refer to unit tests. Unit tests are executed quickly and have extensive coverage. According to the principle of the test pyramid, the coverage rate of unit tests should reach 100%!
After reading the three books "Refactoring", "JavaScript Test-Driven Development" and "The Way of Google Software Testing", I found the reason why I had to start writing tests:
(1) Tests are living documents. Code is for people to read, and tests are easier for people to understand than comments;
(2) Testing facilitates refactoring. Code with unit tests has lower operating costs when expanding and refactoring functions;
(3) Testing can improve code quality. Once you start writing tests, you will find how chaotic your code organization is, and you will force yourself to design from the source of the code to solve the problem, write testable code, and reduce the complexity of the code cycle.
In view of this, I made up my mind to write unit tests for my project, and I already have a vague idea of how to write them.
The reason everyone struggles to get started
There's been a lot of talk above, but everyone understands it. "I understand the truth, but I just find it difficult to start." So before we start, we have to answer two questions, which is why most people are reluctant to start writing tests:
Writing tests can incur a huge cost to the developer
To achieve or approach 100% unit test coverage, the amount of code basically doubles. For example, the well-known acceptance testing tool FitNesse has 64,000 lines of code, of which 28,000 lines of code are unit test codes (data from "Professionalism of Programmers").
This is a daunting ratio. I once believed in the view that "writing tests will bring great costs to developers", until I saw this sentence, and I will share it with you here:
Some people will tell you that TDD reduces defects, but there is a cost, you will write twice as much test code as production code, so it will slow down. The assumption that the factor that affects software development is typing speed is not true, the actual factor is reading requirements documents, writing documents, meeting, locating and fixing bugs.
This sentence will not be interpreted, let’s take a closer look.
Various difficulties encountered by the front end in the testing field
That is to say, those issues we mentioned in the introduction, since it is very difficult to get started from the above perspective. Then we might as well start with two other basic facts to see if we can improve.
(1) There are some tools in each project to handle the common business logic of several components, such as the conversion of specific time and date, etc. These methods are usually distributed in ordinary ts files or service.ts.
(2) A large number of pipes are used in Angular projects. Pipe is actually a function that processes input and output and has a stable logic. Seeing these two points, I believe that the specific function name may have appeared in your mind, and we will start from here Part of the code begins.
how to start
Create a spike
The so-called spike (Chinese can be translated as [lightly thorn]) means that when we are faced with an unfamiliar technical field, we first put aside the existing things and quickly build a demo from scratch to investigate Whether our direction is feasible. Everyone should have the experience of using spike to solve problems in their daily work, especially when doing work with a technical rehearsal nature. It's just that many people may not know how to describe this process.
Back to the text, the situation most teams are likely to face is that my code is currently working well (at least not bad), and each iteration has a lot of requirements to do. There has been no tradition of writing tests in the team, and no one cares. It is indeed a hassle to integrate unfamiliar technical fields in such a rapidly evolving project. So, let's make a spike first. Complete our exploration of Angular unit testing by creating a new project with ng-cli. In spike, we can throw away all specifications and design-level constraints, just for exploration and verification.
First, we create a new project with ng-cli, which couldn't be easier:
ng new spike-testThen:
cd spike-testng test
Just like the above, we have completed one of the simplest projects including unit tests. This process only took you about 3 minutes? Now let's take this project apart to extract the necessary information and integrate it into our existing project.
View the composition of the test through spike
Mainly look at the file app.component.spec.ts.
From this test file, we can see that to complete a test, we must first introduce some test-related packages and tested components (or services, pipelines or even ordinary ts files).
A test suite (describe) will contain several should, that is, the behavior that the test should verify. In this example, it is the following three points: the app should be created, the title should be spike-test, and the title should be rendered in the h1 tag .
In addition to this, many related configuration files need to be used. But overall, it's pretty simple. That being the case, let's get started and integrate test cases in existing projects.
Finally: If you don’t want to experience the feeling of not being able to find information when learning, no one answering questions, and giving up after persisting for a few days, here I will share with you some learning resources for automated testing, hoping to give you some guidance on the way forward. Come to help, friends can get it for free if they need it 【保证100%免费】
Collection of software testing interview questions
Our advanced study of automated testing must be to find a high-paying job. The following interview questions are the latest interview materials from first-line Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. After completing this set of interview materials, I believe everyone can find a satisfactory job.
How to get the video file:
