JUnit Source Analysis (iii)

Three, micro--execution process and code style











Go through JUnit's execution process, so you can have a clear understanding of junit, although as a user this is completely unnecessary. Bring a junit flowchart directly from the JUnit in action.



Oh, maybe you are dizzy, I come to the present guide. As mentioned above, Testrunner is a subclass of Basetestrunner, with one testrunner in three different UI packages. Here we only take the example in the Junit.textui package.











How did the Testrunner get started as an entry program? Accustomed to the use of containers we may now rarely consider this issue. So let's look inside the Testrunner class, you see, you found this:











public static void Main (String args[]) {











Isn't this the main method that we often deal with when we write small desktop programs? Yes, it's that simple.











From this main method entry, first JUnit will parse the command-line arguments and then check whether the test class contains a standard suite method, and if so, the contents of the method (see figure 0, 1); If not found will automatically generate a testsuite, This skips over 0 parts of the diagram and passes the test case class as a parameter (see Part 1 of the figure).











With a Testsuite type object, you can now run the test, but load TestResult and Testlistener objects (see Part 2 in the figure) to monitor and record the test results information before running. The rest of the diagram can be easily read, you can refer to the source view.



Here's my little question. Note that JUnit practice prompts you to place the initialization steps common to each test method in the test class in the Setup method. This seems to give you the illusion that you will think that the statements in Setup and teardown will run only once for all the test methods in a test class. But in reality, JUnit is surprisingly implemented, and setup runs back to each test method in the test class. This means that the common initialization code you put into the Setup method is simply a reuse of the code structure and does not play any role in optimizing the system. For example, if you initialize a database connection in Setup, the process will be executed more than once, which can be a bit .... Let's take a look at the code:











Theclass for the resulting testcase class, name is one of the methods of this class











static public Test createtest (Class theclass, String name) {











Constructor constructor;











try {











Constructor= Gettestconstructor (Theclass);











......











Object test;











try {











The following is to get a TestCase object and pass the method name to the 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});











}











......











returns this object











Return (test) test;











}











Then look at the code at the run, the following method is run in the middle of the setup and teardown











protected void Runtest () throws Throwable {











FName is the name of the method that the TestCase object has.











Assertnotnull (FName);











Method runmethod= null;











try {











To get a method from reflection based on the method name











Runmethod= getclass (). GetMethod (fName, NULL);











}











......











Executing test methods











Runmethod.invoke (this, new class[0]);











......











}











This is probably a process that runs the setup and Teardown methods every time you execute a test method:



Well ..., maybe it's for the old version, maybe it's .... Fortunately, JUnit provides a remedy for the extended class, which is the testsetup we mentioned above, which really implements the extraction of the setup and Teardown methods in this class. When you use it, you can implement your own setup, teardown method by inheriting it and use it in a way that is unique to the decorative pattern.



In the reading process, the code style to give me the most obvious feeling is that the code is basically more to do the refinement, each function point extracted separately to a method, so as to improve the reusability of the code. But in the reading, in the method of frequent jumps, it is not a good thing, without the help of the IDE, I have to faint.











So I think it's important to stick to the principle of improving code reuse: Do it again when necessary. That is, when you start writing code, don't think about reuse and extension, only when you really need to reuse a piece of code or extend the system, do it (remember the metaphor in one of the cows ' books: Let the first bullet hit You).











The old version of Java collection is used in JUnit, presumably because the original version of JUnit did not have a new collection launch. This code should not be in the code we are writing now, please note.












Iv. Summary








Iv. Summary









Iv. Summary










Well, basically analyze the JUnit code and don't know what you've learned. I hope this paper can play a role in the study.