Third, microscopic - implementation process and code style
Let's have a clear understanding of JUnit, so you can have a clear understanding of Junit, although it is unnecessary as a user. Take a JUnit flow chart directly from "JUnit In Action".
Oh, maybe you have dizzy, I am going to travel. Testrunner has a subclass of BaaseteStrunner, with a Testrunner in three different UI packages. Here we are only in the JUnit.Textui package.
How is Testrunner started as an entrance program? We are used to using the container we may now rarely consider this problem. Then we found it in the Testrunner class, you see, you found this:
Public static void main (string args []) {
Is this a MAIN method that we often deal frequent when we write small desktop programs? Yes, it is so simple.
From this MAIN method, first, JUnit will analyze the parameters of the command line, and then check if the test class contains the standard Suite method, if there is an execution method (see 0, 1 in the figure); if not found A TestSuite will be automatically generated so that the 0 part in the figure is skipped, and the test case class is incorporated as the parameters (see 1 in the figure).
It has been a TestSuite type object, and now you can run test, but you should load TestResult and TestListener's objects before running (see section 2) to monitor and record test results information. The rest can be easily understood in the picture, you can refer to the source code to browse it.
Here is my question. Note that JUnit practice prompts to put the initialization steps of each test method in the test class into the setup method. This seems to give you an illusion, that is, you will think that SETUP and TEARDOWN's statements will only run once for all test methods in a test class. However, actually JUnit is unexpected, setup runs back to each test method in the test class. It means that you put the public initialization code in the setup method is only reused on the code structure, and there is no role of any optimization system. For example, you initialize the database connection in Setup, then this process will be executed, this is a bit ... Let's look at the code:
// Theclass is a TestCase class, Name is one of these
Static Public Test CreateTest (Class Theclass, String Name) {
Constructor;
Try {
Constructor = GettestConstructor (Theclass);
......
Object test;
Try {
// The following is to get a TestCase object and incorporate the method name into this object.
IF (constructor.getParameterTypes (). Length == 0) {
Test = constructor.newinstance (New Object [0]);
IF (Test InstanceOf Testcase)
(Testcase) Test .SetName (Name);
} else {
Test = constructor.newinstance (new object [] {name});
}
......
// Return this object
Return (TEST) TEST;
}
Look at the code of the run, the following method is to run in the middle of Setup and Teardown.
Protected void runtest () throws throwable {// fname is the name of the method owned by the TestCase object
askERTNOTNULL (FNAME);
Method Runmethod = NULL;
Try {
/ / According to the method name, the method is obtained by reflection
Runmethod = getClass (). getMethod (fname, null);
}
......
// Execute test method
Runmethod.Invoke (this, new class [0]);
......
}
This way, every time you perform a test method, you have to run a setup and Teardown method, which is probably such a process:
Well ... maybe this is for a compatible version, perhaps ... Fortunately, Junit offers a remedial extension class, which is the TestSetup mentioned above, which is truly implemented in the class, and the extraction of the TEARDOWN method. When you are using, you can implement your own Setup, Teardown method, and use the decorative mode unique call mode.
During reading, the most obvious feeling on the code style is that the code is basically refined, and each function point is extracted separately into a method, which improves the reuse of the code. But when reading, frequent jumps in the method, it is not a good thing. If there is no IDE help, I don't have to faint.
So I think it is necessary to adhere to such a principle on improving code reuse: When you need it, you will start again. That is, don't consider what reuse and expansion when you just start writing code, only when you really need to multiplex a code or extend the system, you can do it (remember to be like this in a certain cattle. : Let the first bullet hit you).
Used in JUnit is the old version Java Collection, which is probably because JUnit initially has no new Collection to be launched. This kind of code should not appear in the code we have written now, please note.
Fourth, summary
Fourth, summary
Fourth, summary
Ok, basically analyze it.
Junit
Code, I don't know what you have learned. It is hoped that this article can play a role in tile jade.
