Unit test what should be measured and what should not be measured

Recently, some friends put forward the opinion, I wrote the article is more empty, write a very long, but very not really. Maybe the reason is this: too little code. Let's start with a piece of code today that describes the process of billing in a telecommunications business system:

User user = User.getUserByServiceId("13309790280");//通过电话号码找到用户
Account account = user.getAccount();//与用户关联的帐户
user.pay(100);//用户缴费100元
//判断用户余额＋帐户的信用度-用户欠费是否大于0
if (user.getBalance() + account.getCredit() - user.getDebt() > 0)
{
Service service = user.getService();//与用户相关的服务
//判断这个服务是否处于欠费停机状态
if (service.getState() == "欠费停机" || service.getState() == "限制呼出")
{
…//向交换系统发出开机指令
}
}

This is one of the most common business systems in the telecommunications business system. The most basic model of the telecommunication system should be "three-door model", which describes a relational model of the concepts of customer (customers), accounts (account), users (user) and services (service), etc. The actual model is a lot simpler than the complexity in the code, and it's mostly used to give an example.

To develop a telecom system, the first thing to do is to implement the most basic models in the system, such as three-user model, online instruction model, business management model, partner model ..., of which three models are in a very important position. The first thing to do is to actually reflect the model in the software system and not to spread it in the various business processes. Then on this basis, from one to two, from two to three, from three to million, to achieve the various subsystems and complex and changeable business needs.

According to the development of TDD, we should write the test code first, then write the actual program, with the test to promote the development of the progress. Here, write the code first, to express the business. Let me just say what the unit test code should measure.

Let's take user for example and now we're going to write the test code for the user class.

What do you need to test?

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

We set up a user object, the user balance is 0, due to the cost of 38 yuan. Now pay 100 yuan, after the completion of payment, the balance should be 62 yuan, owe the fee should be 0, this is a case.

We set up a user object, this user balance is 30, due to the cost of 0. Now pay 50 yuan, after the completion of payment, the arrears should still be 0, the balance should be 80 yuan. This is the second case.

We set up a user object, the user's balance is 0, due to a fee of 150 yuan. Now the payment is 70 yuan, after the completion of the payment should be 80 yuan, the balance should be 0. This is the third case.

What we should be testing is the external expression of the user class, not how he implements it.

At the time of testing, we need a stable environment that can be repeated (the real environment is often not), and sometimes it is not possible to directly create user objects (such as the user object depends on a dataset), sometimes the real environment is difficult to implement some test conditions (such as boundary value, abnormal value). At this point, we can use the mock, stub method, the user to build up, also set up the environment, and then test user performance.

What's not to be measured?

Let's take the user example, or test the pay method, we should not test these things:

How to implement the fee, the cost is saved to which data table in which field, whether it conforms to some kind of data relationship.

After the payment of the balance, arrears in accordance with what variables to add or subtract from a data field to get their own values. This doesn't have to be measured. The user class should be responsible for its own cost issues and should not expose any business logic to other classes (where costs are saved, what data structures are stored, and user is responsible). The outside world cares only about user performance.

After payment should not be sent to the switch boot instructions, this is not required to test, this is the user's caller should be responsible for the matter.

What does the test code guarantee?

The test code only guarantees that the interface is correct, and that the business is not correct is not the most concerned about. For example, user's test code, user to save the cost in the data table, or write in the file, he is not concerned about. Even if there is no lasting preservation, he does not care, as long as the interface is correct through. Of course, errors inherent in implementation are always expressed through interfaces. If user does not save a fee, when we create another user object with the same ID in another space, we get the wrong balance and owe fee.

What is the use of unit testing?

From a certain point of view, unit testing does not guarantee the correctness of the business, but only to ensure the correctness of the interface (strictly speaking, even the correctness of the interface is not guaranteed, he can only ensure that the interface "no these errors"). If a class is always working silently, not providing an interface to tell the outside world what he has done, testing his business is difficult (and should not be tested, otherwise must meddle in his business). So what's the use of unit testing?

Unit tests ensure that the module is modified for compatibility. Unit tests can be used to determine whether a module is modified to be compatible with the modification, to what extent it is incompatible, and how much scope is affected. Developers can focus more on the business within the module. Unit test can not replace the manual work, he is able to measure whether a module changes will affect the work of other modules. This has great benefits for program maintenance and upgrades.