Write test cases for interfaces

Although in traditional testing theory, testing has almost accompanied the entire development cycle: unit testing, integration testing, system testing, and acceptance testing. However, most of the time we encounter is that, at least before the project starts integration, the test basically does not exist. Program The engineer does not want to spend time writing tests after the module is completed. Code (In fact, many programmers even owe it to documents), while testers do not write test code (code writing is usually caught and written ). In fact, even if testers are willing to write test code to perform unit tests on the code, this division of labor is not cost-effective because it introduces additional communication costs between people. Therefore, our tests usually start at the integration stage, so we have to deal with possible module quality problems, module design problems, and many other problems that should have been solved before that.

This situation is unimaginable in traditional industries. You cannot imagine that Boeing did not perform a decent test on its parts before starting assembly, but you often see that we integrate a lot of code that has not undergone unit tests. Is there any internal logic error in this module? Does it have memory leakage? Can it cope with those extreme boundary conditions? Does it meet the requirements? I don't know. I'll try it out first. Then we'll pass the test if we don't find any problems. Then you stare at the weekly bug list and see that the number of bugs is gradually decreasing, gradually approaching the factory requirements, and then you wipe the cold sweat on your head: "Thank God, it seems that this time has passed again ". However, it is inevitable that one day your mailbox will be filled with complaints from users, telling you that your program has a problem somewhere unexpected.

Where is the problem? The problem is that we require programmers to complete the development of a set of things after the development, and these things are not part of the software to be developed and will be discarded at the end of the project. For a programmer, this means that he can perform additional tasks that are not originally needed. This is very difficult to accept, even if he can understand the importance of doing so. This is a weakness of human nature. So how can we further develop the test and ensure the quality of each component of the software as much as possible? This requires us to let the test-driven development process go, so that the commitment to requirements is directly transferred to the development of each component.

In the detailed design process, the requirements can always be decomposed into modules, and the interfaces between modules are determined. After that, it is the official development. So for each module, "What functions does this component implement ?" "How will it be used ?" Such a requirement is always completely reflected in the interfaces of each module. That is to say, to ensure that the use of interfaces is correct, the final quality of this module is guaranteed. Then, we should first write the test code for the module interface, so that we can determine whether our module meets our needs during future development. That is to say, we advance the unit test to the development of the unit code.

Writing Test code first brings many benefits. First of all, in many cases, the requirements are unclear or incomplete, so the process of writing test code is to clarify the requirements, which frees future development from a lot of trouble and disputes. Secondly, this allows us to maintain a detailed unit test code throughout the development process, which is essential in code refactoring. Finally, writing test code first will affect the programmer's psychology, so that they pay attention to the user's needs and experience, rather than simply trying to implement module functions and avoid being found wrong.

Then, these tests will determine how to write the code throughout the development process, because these test codes represent the interface standards, and interfaces are the embodiment of requirements. For this development mode, Peter Coad provides the following description:

A. compile and maintain a detailed unit test.

A. You must first establish the relevant unit test and acceptance (Acceptance) test, and then write the code according to the test.

A. the test determines how to write the code.

Below we will summarize the points we mentioned above:

1) For interface development, make the interface representative requirements

2) use a test to evaluate whether the interface meets the requirements, and maintain sufficient detail in the development process.

3) Use tests to ensure code quality when code changes, such as code modifications and refactoring.

From a higher perspective, test-driven programming actually introduces the test's assurance of the overall quality of software into the development of software units, so that the quality of the entire development process can be further monitored.