Refactoring serial on a tightrope on an insurance cord

When we begin to refactor the system, we do not start to modify the code, but first establish the test mechanism. No matter what the program, as long as we are modified, theoretically can introduce bugs, so we have to test. Since it's a test, you have to have a right or wrong standard of judgment. In previous tests, the criteria for their evaluation were whether they met business needs. As a result, testers often always hold the requirements document testing system.

Unlike previous code modifications, refactoring did not introduce any new requirements, what functions the system used to do, and after refactoring these functions. As a result, there is only one Test standard for refactoring, which is exactly consistent with previous functionality, and that's all.

However, in many classic refactoring books, the gurus always suggest that we first set up automated test mechanisms that have been proven unrealistic in countless practices. You know what we're refactoring now is a legacy system that is often cluttered with design clutter, interfaces that are not clear, and programs that depend on each other. All this makes the initial automated tests very difficult and impractical.

Therefore, it is impractical to implement automated testing from the outset, and we can use manual testing. Before the reconstruction, the system starts up, performs the corresponding function, obtains each corresponding output. Then you start refactoring, not too much to change the code every time you refactor, not to take too long. Because, the amount of modification is too big, take a long time, once the test does not pass, it is difficult to locate the cause of the error. In this case, we can only restore the code, the work of this modification completely void. If this change has taken you several days or even months, the loss would be too great.

Every time you refactor, modify a little bit of code, and then commit to test the system once. If the system remains as functional as ever, refactoring succeeds and continues the next refactoring. If not, you have to revert back and refactor again. Testing frequently makes you annoying, but it effectively reduces the damage that refactoring fails to bring you. A compromise approach is that, usually when the test, the test project less, only to test the main projects, regular and comprehensive testing. Recording Qtp[1] Script is also a good way, although it has a lot of problems, but it can be in the early stage of system reconfiguration to effectively establish automated testing, system-level automation testing. As the system continues to refactor, our programs begin to improve, the coupling becomes more and more loose, the programs become more and more cohesive, and the interface becomes clearer. At this point, when the automated test conditions are ripe, we can gradually start to automate the test, which is the real automated test built at the code level.

Once a modification test is not passed, restore it back. This one small step change model, we call it "small step run". In the continuous monitoring of the test Integration Tool 1.1 point to modify the program, is the system to restructure different from the previous one. Running through small steps can make us in the process of refactoring, the fastest speed to find changes in the problem, will be due to modify the error to minimize the loss, after all, it is impossible for people to avoid making mistakes.

[1] The abbreviation of Qtp,quicktest Professional is an automatic test tool. The purpose of using QTP is to use it to perform repetitive manual tests, primarily for regression testing and testing of new versions of the same software.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/