Nowadays, more and more development organizations use unit testing in program development, and even some outsourcing projects require a complete unit test code when the developer is delivered. Unit tests need to be considered not only when encoding, but should be fully considered in the program design, design and write "test" code. Why is some code difficult to test when performing unit testing, it will find that some parts of the program are difficult to test, such as classes, user interfaces, databases, servlets, and EJB classes, and so on. This article mainly shows what kind of way these "difficult test" should be used in the program to test. What is the factor makes these code difficult to test? The first is not to know what is measured, followed by some of the code, dependence on each other, is difficult to establish these classes in the test environment. What we should measure should first assume that some parts do not have problems: assuming that the bottom class of Swing or MFC is no problem; assuming Oracle, SQL Server, etc. is no problem. What we need to do is to separate our own code and these codes from physically, so that we can test it. As for servlets, you can use HTTPUnit or use a program call to test. Test high-coupled classes We look at the following procedure: There is a CoffeeMaker class in the program, and we want to test it with the CoffeeMakertest class. When the CoffeeMaker class works, you need to call the Warmer class and the Boiler class. Suppose these two classes are difficult to create in the test environment, how should this be tested? For high coupling classes, it is in fact always reducing coupling between classes through a certain programming method. Please see the example below: In the left, A and B are closely coupled together. In order to reduce this coupling, in the figure on the right, the IB interface is introduced in the program, and the class A can be worked as soon as it understand the IB interface. In the actual operating environment, you can use the Class B implementation IB interface to actually work. In the test environment, you can implement a virtual IB in the mouth, you can test A aspect. When the test is tested, if the above figure, in real operation, the IB implementation class is B. When the test is tested, it is difficult to create an instance, so create an instance of the BSTUB class in the test program. BSTUB is specifically created for testing, the ATEST class controls his input and output. If you simplify the above situation, you can further: The test class itself is an implementation of the IB interface, so you don't have to write a new class, as follows: Use the above description, reduce the coupling between the class, below Coffee Maker The program has been improved, and the degree of coupling between classes is greatly reduced, which is convenient for testing. Methods similar to the STUB class described above have a wide range of applications in unit testing. This method requires the relationship between the class and classes to interface, not based on the interface, not based on the interface. This way will also bring maximum flexibility to procedures. Generally speaking, the following modules should be called by interface: 1: Hardware; 2: Database; 3: Class has not completed yet. Test the user interface Test the user interface is a problem that should be considered when designing (once again, it is necessary to consider when designing). Unit testing of user interfaces, requiring programs to have better hierarchies, and user interfaces and business logic behind them are separated. That is, the user interface is only a thin layer, and the degree of coupling between the user interface and the service logic is small, and the module is relatively loose. This kind of implementation is easy. The background business logic can be tested independently, and the front desk can write a fake background interface implementation test. Basically all things can be automated.
