Demand, interface and test
- I see test driver development (1)
SpaceSoft [Dark Night Sand]
The software engineering community has always existed, "" Programmer should not test their own code ", because the thinking of the programmer's thinking of the code development will inevitably lead to the test of the blind zone, at the same time, for personal feelings Personally, it is difficult to veto their efforts to complete the results of work.
This concept makes the professional test team have become possible, so, in modern software development, the intervention of professional test teams makes the quality of the software have been considerably safe. Testing became the last sentinel card for software quality assurance, began to have achieved increasingly important positions with the attention of software quality and reliability.
However, the research of software engineering also tells us another point of view: the earlier discovery error in the software development cycle, the less the loss will bring the loss. The following charts are taken from the << Practical Software Metrics >> (CAPERS JONES, McGraw-Hill 1991), lists the time spent on preparation test, execution test, and modification defects (based on a function point), The cost efficiency of the unit test is approximately three times the two-fold system test of the integrated test (see bar chart).
Despite the traditional test theory, the test is almost accompanied by the entire development cycle: unit test, integrated test, system test, acceptance test. However, more time we encounter: Test is substantially not existed at least before the project starts integration. The programmer does not want to take the time to write test code after the module is completed (in fact, many programmers have owed documents), and testers will not write test code (can write code, usually have been caught Code). In fact, even if the tester is willing to write test code to complete the unit test of the code, such division of labor is not cost-effective, as this introduces an additional exchange cost between people. So our testing is usually starting in the integration phase, so we have to face the possible module quality issues at this time, module design issues, and many other problems should have been resolved before that.
This situation is unimaginable in traditional industries. You can't imagine that the Boeing aircraft did not have a similar test for its parts before starting the assembly, but you often see that we integrate a lot of code that does not have a unit test. Does this module have internal logic errors? Is it a memory leak? Can it cope with those extreme boundary conditions? Is it a demand for demand? I don't know, I will fight first, I will put us too much. Then you stare at the weekly bug list, see the BUG gradually decline, gradually approaching the factory requirements, then you wipe the cold sweat on your head: "Thank God, it seems to pass again." However, there will be a day, and your mailbox is full of complaints from the user, telling you that your program has a problem in a certain place you can't think of.
Where is the problem? The problem is that we ask the programmer to complete a set of things after completing the development, and these things are not part of the software to develop, and will be abandoned at the end of the project. For programmers, this is equal to the additional more tasks that have been completed, which is difficult to accept, even if he can understand the importance of this. This is the weakness of human nature. So, how do we let tests further in-depth development processes, ensure that the software is the quality of each component? This requires us to let go of the process of testing drive development, let the commitment to demand directly into the development of each component.
In the process of detailed design, the demand can always be broken down into the module and determine the interface between the modules. Then it is formally developed. So for each module, "What is the function of this component to implement?" "How will it be used?" This needs always reflected in the interface of each module, that is, guaranteed the use of the interface. The final quality of this module is guaranteed correctly. So, let's take a step, write the test code for the module's interface, so when you develop, you can determine whether our module has reached our needs. That is, we put the unit test in advance, before the development of the unit code in advance. The test code has brought a lot of benefits. First of all, in many times, demand is unclear or incomplete, then the process of writing test code is the process of clearing the demand, which makes the future development except for many troubles and disputes. Second, this makes us to maintain a detailed unit test code throughout the development process, which is essential in code reconstruction. Finally, write test code will affect the psychology of the programmer, enabling them to pay attention to the user's needs and experience, not just intend to implement the functionality of the module and avoid being discovered.
Then, we will determine the code through these tests throughout the development process, because these test code represents the standard of the interface, and the interface is the incarnation of demand. For this development mode, Peter COAD gives the following description:
a .. Write and keep a detailed unit test. A .. To establish a related unit test and acceptance test, then write code based on the test. A .. By testing to determine how to write code.
Let's summarize the points mentioned above:
1) For interface development, make interface representative requirements
2) Whether the test evaluation interface meets the needs, and maintains enough detailed testing during the development process
3) When the code changes, reconstruction, etc., use test guarantee code quality
In the view of higher levels, test-driven programming is in fact to introduce tests to software units to the development of software units, making the quality of the entire development process further monitoring.
Welcome to the author's personal homepage: http://www.mrspace.net/
