What should be tested in unit testing, and what should not be tested?

I read an idior article just now.Article: Enterprise test driven develop. After reading this article, I will write down this article and talk about my views on this issue: What should I test in automated unit testing.

Recently, a friend raised his opinion and thought that the articles I wrote were empty and very long, but they were not real. The possible cause is:CodeToo few. Let's start with a piece of code today, which describes the process of starting a payment in the telecom business system:

User user = User. getuserbyserviceid ( " 13309790280 " ); // Find a user by phone number
Account account = User. getaccount (); // Account associated with the user
User. Pay ( 100 ); // User pays 100 yuan

// Determine whether the user balance + account credit is greater than 0 if the user is in arrears
If (User. getbalance () + Account. getcredit () - User. getdebt () >   0 )
{
Service = User. getservice (); // User-related services
// Determine whether the service is out of service due to overdue payment
If (Service. getstate () =   " Suspended due to overdue payment "   | Service. getstate () =   " Restrict outbound calls " )
{
...//Issue boot command to switch system
}
}

This is the most common service in the telecom business system. The most basic model of the telecom system should be the "Three-user model". The three models describe the customer, account, user, and service) and so on. The actual model is much more complex than the code, which is simplified here. It is mainly used as an example.

To develop a telecommunications system, you must first implement the most basic models in the system, such as the three-user model, online instruction model, business processing model, and partner model ......, Three of them are in a very important position. The first thing we need to do is to reflect this model in the software system, and never implicitly spread it in various business processes. Then, we can achieve various subsystems and complex and variable business needs from one to two, from two to three, from three to ten thousand.

According to the TDD development idea, we should first write the test code and then write the actualProgramAnd use testing to promote development. Write the code to express the business. Next I will talk about what the unit test code should test.

Let's take the user for example. Now we want to write the test code for the user class.

What should I test?

We need to test the external performance of the user class. For example, to test the pay method, we should:

We create a user object. The user balance is 0, and the overdue payment is 38 RMB. Now you have paid 100 yuan. After the payment is complete, the balance should be 62 yuan, and the overdue payment should be 0. This is a case.

We create a user object with a balance of 30 and zero overdue payments. Now you have paid 50 RMB. After the payment is completed, the overdue payment should still be 0, and the balance should be 80 RMB. This is the second case.

We create a user object. The balance of the user is 0, and the overdue payment is 150 RMB. Now 70 yuan is paid. After the payment is completed, the overdue payment should be 80 yuan, and the balance should be 0. This is the third case.

We should test the external performance of the user class, instead of asking him how to implement it.

During the test, we need a stable environment that can be repeated (the real environment often fails), and sometimes the user object cannot be directly created (for example, the user object depends on a dataset ), sometimes it is difficult to implement some test conditions (such as the boundary value and non-normal value) in a real environment ). At this time, we can use methods such as mock and stub to set up the user, set up the environment, and then test the user's performance.

No need to test anything?

Take the user for example or test the pay method. We should not test these things:

How is the payment realized? The fee is saved to which field of the data table and whether it conforms to a certain data relationship.

After the payment, add or subtract the balance or overdue payment according to the variable or get your own value from a data field. This does not need to be tested. The user class should be responsible for its own charges, and should not expose any business logic to other classes (where and what data structure the fees are stored, the user class should be responsible ). The outside world only cares about the performance of users.

After paying the fee, you should not send the boot command to the switch. This does not need to be tested. This is the responsibility of the user caller.

What does the test code ensure?

The test code only ensures that the interface is correct. Incorrect business is not the most important thing. For example, if the user's test code saves the fee in the data table or writes it in the file, he does not care about it. Even if there is no persistent storage, it doesn't matter, as long as the interface passes correctly. Of course, internal implementation errors are always displayed through interfaces. If the user does not save the user's payment, when we create another user object with the same ID in another space, we will get the wrong balance and overdue payment.

What is the purpose of unit testing?

From a certain point of view, unit testing cannot ensure the correctness of services, but only the correctness of interfaces. (strictly speaking, the correctness of interfaces cannot be guaranteed, it can only ensure that the interface "does not have these errors "). If a class is always working silently and does not provide interfaces to tell the outside world what he has done, it is very difficult to test his business (and should not be tested, otherwise, it is necessary to intervene in his business ). So what is the purpose of unit testing?

the unit test ensures the compatibility of the modified modules. Unit tests can be used to determine whether a module is compatible with the modification, to what extent it is incompatible, and the scope of impact. Developers can focus more on the internal business of the module. Unit testing cannot replace manual work. What it can do is to determine whether a module will affect the work of other modules after modification. This is of great benefit to program maintenance and upgrade.