Understanding of unit testing-a double-edged sword

I thought that my graduation design was a test-driven development, so I had a deep understanding of unit testing and test-driven development since the beginning, and I have been a loyal fan of agile development at the beginning. However, after several years of work, I began to have a conflicting attitude towards unit testing: unit testing is of course a great initiative, but it often produces side effects in specific use. Of course, this is not because of the thinking of unit testing, but the problem of people who practice this idea.

 

At present, many companies use unit testing as a strange phenomenon:
Many companies follow agile development to make it look good.
100% unit test coverage, soCodeThe quality is very reliable. However, in fact, unit tests are all added after the software has been developed, and are often written by specially assigned persons.
Unit testing, and these people are not familiar with the requirements at all, even not involved in the development process, or participate in very little, and the time allocated to them to write unit test code is of course very tight, this is also the cost.
. Therefore, the final result is: to achieve the coverage goal, add unit tests for each method (no matter whether necessary). Let's take a look at this method, then, starting from a superficial understanding of this method,
I started to write one or a few test cases, so that the unit test coverage rate is 100%, but is such a unit test useful? The answer is self-explanatory.

 

What are the common characteristics of this strange phenomenon?

1. Write unit tests after the entire development process-this is the timing of Unit Tests

2. Write unit tests by non-developers -- this is the role of the performer of unit tests.

3. Write unit tests by people who do not understand the requirements-this is also the role of the performer of unit tests.

 

So what are the side effects of such behavior?

1. This wastes time and labor costs.

2. This will bring negative emotional impact

These people are engaged in work with resistance and boredom, because they know that such a job is useless, only a face project, but have to do it. Naturally, they are not interested or enthusiastic, this sentiment is distributed both horizontally and vertically, which negatively impacts the team.

3. These unit test codes are useless and even have negative effects.

For later users, this unit test code does not have any function, because the author simply writes the code without understanding the requirements, so naturally there is no benefit for the later users to understand the needs; in addition, if the unit test code that the latecomer believes is not fully investigated for the specific implementation code, there will be misunderstandings.

 

How do I write unit tests? When to write?

This is a question worth exploring, but it is necessary.

On the cool shell, we can see how detailed the unit test is.ArticleThis article is introduced from a problem in stackoverflow.

 

This problem is:

TDD takes time to write tests, but we usually write some code. The first test is to test whether my constructors have set all the variables of this class correctly, will this be too much? So what is the granularity of the unit we write unit tests? What's more, isn't our test much better?

 

The best answer is:

The boss pays for my code instead of testing. So, my value for this is that the less test, the better, the less
You have achieved some confidence in your code quality (I think this confidence standard should be higher than the industry standard, of course, this confidence may also be arrogant ). If I don't make such a typical mistake in my coding career
(For example, if an incorrect value is set in the constructor), I will not test it. I tend to test those meaningful errors, so I am very careful about some complicated conditional logic. When
In the team, I will be very careful to test the code that will make the team prone to errors.

 

After reading this best answer, I feel a certain negative attitude towards unit testing and a cold attitude. But who is the respondent who knows the best answer? It's Kent.
Beck. Yes, it's the extreme programming, test-driven development, unit testing, and Kent Beck, the creator of JUnit. Kent
Beck's answer exactly answers the questions about how to write a unit test, how much to write, and when to write a unit test.

 

Some of my points:

There are several points of view on how to perform unit tests:

I. Timing of unit testing is important

There are only two types:

First, before the specific implementation code, this is the so-called test-driven development;

The second is to synchronize with the specific implementation code, which is exactly the way most people use.

Subsequent unit tests are useless. Of course, there is an exception: To maintain and transform existing code without unit testing, you need to append a unit test for the existing code at this time, however, this must be based on a thorough investigation and understanding of the needs.

Ii. Role of the executor of unit test

Unit tests should be carried out by developers who implement code. That is to say, each developer should be responsible for the specific implementation code and unit test code at the same time.

The exception in the first article also exists.

Iii. Emphasis on unit testing

Focus on those important parts, including:

1. complicated logic

2. error-prone

3. Hard to understand. Even if you forget your code for a while, you cannot understand your code. unit test code helps you understand the functions and requirements of the Code.

4. There is a relatively high possibility of demand change in the future. After the demand changes, you don't have to worry too much about whether the written code is correct or not and whether the existing code logic is damaged.

4. unit testing should also focus on quality and do not write useless unit test code.

It is better to write unit tests that are useless to actual use. Just like annotations, it is better to write meaningless annotations.

 

The last thing to say is:

Stupid unit tests for unit tests should be stopped immediately.

The behavior that just wants to take unit testing as a face project should be stopped (the bad habits of officialdom should not be in the pure IdeologyProgramPopular ).

Those teams that do not have a deep understanding of unit testing, but want to win the "unit test coverage rate of 100%" title in the future, should immediately stop this idea.

Unit tests should not focus too much on coverage, but should write unit tests as needed. The time to write and how to write should be based on the deep understanding of unit testing by developers.

unit testing is also a double-edged sword. Only when it is used well can it shine and generate strong positive energy. Please do not treat it as a "Longquan Sword" and stick it to your own secret.