Writing in the front

In the first half of the Internet, 2C business occupies the absolute majority of the market. Its business is characterized by “short, flat and fast”, fast trial and error, fast iteration, out of the fast, die fast. In this environment, the speed of feature iteration is a matter of life and death, and nothing is more important than that. Single test? Wait for this (next, next…) Let’s do it after the iteration.

With the development of the Internet into the second half, 2B business began to rise, the industry also began to appear a lot of excellent tools. This means that the weight of business quality and stability is much higher. That’s when stability becomes a matter of life and death. Imagine a 2B business because of the new function online, there is 1h unavailable state, this will be disastrous. The rules of the game have changed and the gameplay has to change as well.

There are too many articles written online about single testing, either introducing tools (Jest, Mocha, Chai, etc.) or scripted about what single testing is. After reading it, I always felt that it could not guide the actual development and was not grounded enough, so I tried to summarize this document, hoping to fill in the missing part. Therefore, this article will not introduce the basic concepts of single testing and single testing tools, but only some methodologies to guide practice.

Why is single-test coverage required?

First of all, “coverage” is not an end, but a means to an end. We hope that:

  • Arouse students’ awareness of code quality through “single test”;
  • Through the “unilateral coverage” index to ensure and promote the implementation of the program;
  • Improve the quality of students’ code by “writing single tests” (why? See the “Revisiting single test” section below);

Therefore, “coverage” is not the goal. While coverage cannot simply be the same as code quality, it does involve deeper changes if you want to continuously improve coverage and maintain it at a high level. As for how to set coverage standards, it is recommended that the project develop a long-term plan to continuously improve and maintain a high level of coverage, as described in “How to Write a good single test” below.

What is not a single test?

Rather than what is a single test, let’s first look at what is not a single test, which may give us more insight:

Tests that require database access are not unit tests

Tests that require network access are not unit tests

Tests that require access to the file system are not unit tests

The art of modifying code

Pure functions, side effects, idempotence, functional programming… If these words come to mind, congratulations, you’re on your way.

What are the benefits of writing single tests?

  1. Safe: This is obvious, and I’m sure you’ve had a lot of confused and scary experiences going online.
  2. Refactor aggressively: Even if you built the system from scratch, you will definitely make the same mistakes when refactoring.
  3. Explanatory: Test cases are your best documentation, even a demo.

So that’s intuitive, everybody knows that, but here’s what’s easy to ignore

  1. Improve your design: If you take single testing seriously, it forces you to write more maintainable code. If you find that your code is not easy or can’t write single tests, it’s probably a design problem. When you think about and refactor that part of the code, it will be worth your time and effort, and you will be less and less likely to write “not testable” code. In addition, it is said that 85% of defects occur during the design phase of the code, and that the later a bug is found, the more expensive it becomes, exponentially.
  2. Improve comprehensive thinking ability: single test often write boundary case, over time this thinking will form inertia, in the future when writing code thinking will be very clear, careful thinking, thorough will also become a habit.
  3. Improving code quality: This step is a natural consequence of the above, so it doesn’t need to be explained.
  4. Save time: Don’t spout on me, I’m just a mover. For an argument, see the art of Unit Testing from Head to toe in Talking about effective unit Testing

What is a good single test?

  1. Correct, clear, concise, and in the practice of unit testing is not only the correctness of the test code, can also help other developers to understand the code logic, understand how to use a class or function (can be used as interface or function of the sample, the province is written using document and demo), so the single measurement were asked to write a clear, concise, have very good readability.
  2. Integrity is also required. Single test should have high coverage, taking into account all possible input and output scenarios.
  3. Robustness is one of the most overlooked items. A good single test should require no or very few changes when the class or function being tested is modified internally or functionality is added. For example, a single test implementation of a sorting function is completely stable; it should not change with different sorting algorithms.
  4. Have a good name that will tell you what the test is, and if it doesn’t tell you what the test is, have a full comment. For example, testSortNumbers_withDuplicated, which means a unit test of the SortNumbers function to verify that there are duplicated numbers.
  5. Simple logic, try to avoid using Imperative Programming (Imperative Programming) to introduce conditional judgment, loop and other complex logic. Otherwise, you’re likely to introduce a lot of bugs into the unit tests themselves, and you’ll need to write unit tests for unit tests… One sentence unit tests do not introduce complex logic, preferably no logic.
  6. Complete without repetition. Do not write multiple unit tests for the same test scenario, or the same type of test input, just find a representative scenario input is ok.

How to write a single test?

Here are just some theories, please combine with practice to improve

The strategy is four steps

  1. Can write, the project has the project, can write single test, everyone can write
  2. Write well, have a sense of whether code is teachable, and know how to write “teachable” code
  3. Refactoring, as single-test coverage increases, some code is naturally refactoring, and a virtuous cycle begins
  4. Normal, when you’re writing new code, you’ve already figured out how to write single test, and you’re doing both at the same time, and it’s normal

Four elements of tactics

  1. Core code priority, focus on single test coverage, such as public functions, public components, etc. At this time, “fine”, in the strategy of 1, 2 stages, to pay attention to the cultivation of internal work
  2. Design the directory structure. Such as constants (no testing) in a separate file, and the uniform name, convenient ignore; UI components and data processing logic are divided into separate files, do not couple; Common components are placed in one directory for easy coverage statistics and so on
  3. Functional programming thinking, as much as possible to reduce the side effects of the function, the most typical is to put the window, localStorage and other global variables as parameters passed in, rather than directly access and operation in the function
  4. The side effects are controlled within a certain range, side effects are difficult to avoid, so they are unified convergence, such as the operation of localStorage, only allowed through a secondary encapsulation function to trigger, similar to the idea of redux, VUEX and other state management mechanism

conclusion

Single testing is a necessary skill for a mature programmer. As stated in the beginning, “the rules of the game have changed”, and we must be aware of this, prepare for the rainy day, and keep up with it. To be honest, before sorting out the methodology, I personally felt that “writing single tests is important, writing single tests should be done, writing single tests can be done without fear of refactoring”, but these vague concepts really weren’t enough to convince me to write single tests. It was not until I led the department’s “quality management” project that I began to think deeply. I began to convince myself to study point by point and solve problem by problem. I thought I had gained another dimension in my understanding of coding. Finally, I hope this article can play the role of throwing brick to introduce jade, to provide you with a train of thought and introduction, but also a merit.

The resources

  • Talk about front-end unit testing
  • Why front-end unit testing
  • Front-end unit testing practices
  • Single testing from top to bottom — Effective unit testing
  • Essential artifact of dry goods | test flat: good unit tests