JBuilder 2005 Unit Test Overview _jsp programming

A product can only be put into the market through testing, the same, a business class and only after the experience test to ensure that the function is correct to be called by other classes or programs, otherwise hidden bugs will spread. Business function Point Testing is the responsibility of testers, but the correctness of business class APIs must be guaranteed by developers.

Recall recently you developed a system, often one of the most memorable plot is a night-night carpet search for a bug, through arduous hardships, finally found and resolved it. Finding a hidden bug is often a break in the heel of the place, and found it is: the solution is not a kung fu.

There are several reasons for this embarrassing dilemma:

One is to use an incremental test strategy, that is, to write the functional code, after the development of the module to write test cases, because a functional module may contain many interrelated classes, formed a layer of calls, staggered complex call network, once found a bug, had to check the account-like one after the investigation, The degree of hardship imaginable.

The second is to use incorrect test methods, such as providing a main () test function in each class, testing the functional methods in the class, and viewing the correctness of the class functionality by running the class's main () method. This may be a commendable work habit in some kind of procedure, but the way of working is unworthy. Because each class must run separately to perform its testing function, the developer observes the correctness of the test. With the expansion of the program scale, the number of classes in a straight up, the original class will also occur code adjustment, some function points may become a slip through the sea, into the vast "class" black account, the future "illegal" up is difficult to monitor.

In view of the shortcomings of these traditional testing ideas, test-first, frequent-test, automated test-testing ideas are accepted by more and more developers and put into practice.

The test first sounds a little weird, and one thing hasn't been done yet, how do you want to test it? Careful analysis, this is not absurd, because this allows you to design the class, from the caller's point of view to understand the external interface of the class, forcing you to understand the external relationship of the class, consider the purpose of the interface, and in the specific program to specifically consider the internal implementation details, so that the design interface will be easier to use, the structure will be more reasonable.

Frequent testing, which means that testing should not be a phased work, but should be in the process of programming. Because there are many relationships among the classes in the system, when the function of the class is changed, many classes are affected directly or indirectly. So you should test frequently to find out the bugs that are caused by features and adjustments early on, and the sooner you find out that the error is less costly to fix. Frequent testing is also an important part of XP programming, XP programming people feel that they pay attention to functional implementation and ignore the test, in fact they are also very concerned about testing, after all, testing can make them as fast as possible steady progress.

Automated testing does not mean that there is a tool that allows you to automatically test the problems in your class like a security device. It refers to the application of a certain test framework for each business class to write a separate test case, after the class code adjustment, the corresponding test case synchronization adjustment. Multiple test cases run in bulk with a test suite, they are like a powerful bug sniffer, and once a bug is discovered it outputs a specific information report error, as long as a test case fails the test to indicate a problem in the program. The test rules included in the test case are completed by you, and the "sensitivity" of the test suite to bug sniffing depends entirely on the test rules for test cases, and the framework provides a prescriptive approach to writing and running test cases.

When writing a business class, you need to write a corresponding test case, the beginning of the "inertia" conflict, because it requires you will create a test case class, it seems to need more work. But your effort will be doubly rewarded, and as the size of the software grows, you'll find that the test technology based on the test framework is still "laughing" when the traditional test methods become more and more stretched and overwhelmed. Of course, when others say so, we should not immediately believe that doubt is always worthy of the scientific spirit, we should through their own practice but really appreciate the joy of this improvement.