Reconstruction and serialization of big talk 3: wire the insurance Cable

When we start to restructure the system, instead of modifying the code, we should first establish a testing mechanism. No matter what program, as long as it is modified by us, bugs may be introduced theoretically, so we have to test it. Since it is a test, a correct or incorrect criterion must be set. In previous tests, the criterion is whether to meet business needs. Therefore, testers often take the requirement document to test the system.

Unlike previous Code modifications, refactoring does not introduce any new requirements. The original functions of the system are still the same after reconstruction. Therefore, there is only one refactored test standard, which is completely consistent with the previous functions.

However, in many typical refactoring books, masters always suggest that we first establish an automated testing mechanism, which has been proved unrealistic by countless practices. We need to know that we are restructuring a legacy system, which is often chaotic in design, unclear interfaces, and program dependencies. All of these make initial automated testing very difficult and impractical.

Therefore, it is impractical to implement automated testing from the very beginning. What we can use is manual testing. Before restructuring, start the system and execute corresponding functions to obtain corresponding output. Then, start refactoring. The amount of modification to the code for each refactoring should not be too large, and the time spent should not be too long. Because the modification is too large and takes too long. Once the test fails, it is difficult to locate the cause of the error. In this case, we can only restore the code and cancel the modification. If the modification takes you several days or even months, the loss will be too great.

Every time you perform a refactoring, modify a little code, submit the code, and perform a test on the system. If the system still maintains the same functions as before, the reconstruction is successful and the next reconstruction continues. If not, you have to restore it and rebuild it. Frequent tests are annoying, but they effectively reduce the loss caused by reconstruction failures. The alternative is that when frequent tests are conducted, the number of test items is smaller, only the main items are tested, and comprehensive tests are conducted on a regular basis. Recording the qtp [1] script is also a good method. Although it has many problems, it can effectively establish automated testing and system-level automated testing at the initial stage of System Reconstruction. With the deepening of system restructuring, our programs are being improved, coupling is becoming increasingly loose, programs become more and more cohesive, and interfaces become clearer and clearer. At this time, when the automated test conditions are mature, we can gradually start the automated test, and this automated test is the real automated test built on the code level.

Once a modification test fails, it is restored. This one-step modification pattern is vividly referred to as "small steps ". Modifying the program at 1.1 points under the continuous supervision of the test integration tool is another feature of system restructuring. Through small steps, we can find the problem of modification at the fastest speed in the reconstruction process and minimize the loss caused by modification errors. After all, it is impossible for people to avoid mistakes.

[1] qtp, short for quicktest professional, is an automatic testing tool. The purpose of qtp is to use it for repeated manual tests, mainly for regression testing and testing new versions of the same software.

Big talk rebuilding serialization home: http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!