I. Testrunner.dorun (Test Suite, Boolean Wait) Method 1, create a TestResult object, the object is the dispatcher during the actual test. He not only stores the results of all tests, the test method in the call, and gives the results to the Resultprinter object to print the results. 2, set the generated RESULTPRINTER object to the TestResult object. 3, get the start time. 4, call the Test.Run (TestResult) method. 5, get the end time. 6. Print the test results. 7. Judging whether you need to wait for the end command, if necessary, wait, "System.in.Read ()" Wait the instruction. Second, TEST.RUN (TestRESULT) Method - TestCase Implementation Test Interface is one of the most important interfaces in the JUnit framework, and he abstracts all test carriers, including two ways, a countTestCases (), a number of tests. Method, a Run (TestResult) method running test. In the JUnit framework, there are two classes to show this interface. One is only a TestCase object that can only accommodate a single test, which is used here because there can be multiple test methods in the TestCase subclass we implement, but in the actual operation of JUnit, each TestCase object only accommodates a test. method. In TestCase's Run (TestResult) method, the actual run test is delegated to the TestResult method, and the TestResult method will call the TestCase Runbare () method, put the results of the test run in the corresponding In the Vector, and notify all set TestListener, where initialization is the set RESRINTER object. In the TestCase's Runbare () method, the initialization setup () method is actually called, and the TEARDEST () method is implemented, and three methods are cleared. TestCase implemented CountTestCases () method only returns 1. Third, TEST.RUN (TestRESULT) Method - TestSuite Realization Another implementation of the Test interface in the JUnit frame is the TestSuite class, the TestSuite class can be said to be a TEST of the Test interface, mainly used to accommodate multiple test methods class. There is a vector instance inside the TestSuite class to accommodate all TestCase objects in this TestSuite. In the JUnit framework, the implementation logic for the Test interface is a more interesting thing. In particular, the TestCase class, he did not use the Run (TestResult) method as we think, using the reflection call subclass's method in the "Test" method, but in the TestSuite class parsing the method names later The TestCase object allows each TestCase object only to accommodate a test method, and call the initial setup () method and clear the teardown () method for this test method. I don't think this doesn't reach "The common variables in all test methods in a TestCase are extracted to the variables of the class, and then initialize together in the setup () method." In this case, we don't have to declare a variable in subclasses. When the square setup () method is for each test method, we will not put all the variables directly in the test method, save the code to become one piece, there is one piece.
I really don't know whether Erich Gamma and Kent Back is what is thinking, and I have a clear hope to give a wake up! Or just after returning, in the Run (TestResult) method implemented in TestSuite, he will call all the Run (TestResult) method of each Test in each vector. TestSuite implemented CountTestCases () method returns the number of items that contain TEST. Fourth, there are two important interfaces in the TestListener Interface JUnit framework, one is the TEST interface described above, and the other important interface-TestListener interface is introduced below. The TEST interface abstracts all the test carriers, while the TestListener interface abstracts all the test listeners, including two ways to add errors and failed: Adderror (Test, throwable) and addfailure (TEST, AssertionFaileDError) methods, start testing STARTTEST (TEST) method ends the test endtest (test) method. There are two classes in the JUnit framework to implement this interface, a Resultprinter class responsible for the results, one is the basic class BaseteStrunner class for all Testrunner. 5. The Resultprinter class Resultprinter class is responsible for printing of all test results. He has two type variables, one is the number of FCOLUMNs responsible for record testing, and went to 40 times, in the zero count. FWRITER is a prints that Printsteam is responsible for printing. STARTTEST (TEST) implemented by Resultprinter, complete the statistics and wraps of the test, and print out what we are familiar with. " The resultprinter () method and addfailure () method implemented only "E" and "F" are printed. There is no done in EDNTEST (TEST) implemented by Resultprinter. Another important way in the Resultprinter class is the Print (TestResult, Runtime) method, and he includes four parts printheader printing time, printerrors (testResult) prints all errors, PrintFailures (TestResult) prints all failed, PrintFooter (TestResult) Print results, that is, "OK (100 Test)". Here is the error and failure in the JUnit frame, Error is an exception reported in our test method, and Failure is our exception to use assertxx () method, judgment failure. 6. In the Testrunner class baseStrunner class, all four methods of the TestListener interface are delegated to the subclass implementation, and in the Testrunner class, these methods have not been done, I think it is possible to use Testrunner to implement test results However, later discovering that all classes should be used to process all these methods in the Testrunner class. However, I want to implement the TestListener interface in the TestRuner class, such as integrating multiple Testrunner in a class. Seven, the Assert class finally talks about the Assertxx () method of the test method, all of which are placed in a class called Assert, because all the test methods are executed in the TestCase class, so the testcase class inherits the Assert class. . There is nothing better than what ASSERT class is a bunch of Assertxx () methods.
