(Since it is written while watching, some content is based on the existing knowledge, not necessarily correct, please correct, thank you)
We test a class, generally to test it.
(JUnit v.3.8.1, analysis of the main classes one by one)
Testcase
The JUnit is divided into TestSuit and TestCase. The former includes multiple latter, the latter generally testing a class. TestCase is an abstract class that must inherit it to write its own test case class. Example from Junit Source Code's Commet:
* Public class mathtest extends testcase {* protected double fvalue1; * protected double fvalue2; * * protected void setup () {* fvalue1 = 2.0; * fValue2 = 3.0;
*}
* // Add whatever u want to test here *}
Next, if we want to test a Method called Add, we have to define TestAdd () in Mathtest, it is best to determine your method in this way: test whatver u want to test (first letter capitalization), The reason is that there is a method of talking about TestCase runs your test method. In fact, if you use Eclipse, you will know that Eclipse automatically generates the method name of the test method according to this rule, then one is that this is also our right. What is the test. For example, our TestAdd () is (ibid):
* Public void test () {* double result = fValue1 fvalue2; * asserttrue (result == 5.0); *}
Now you have two ways to run this TestAdd (). The first is as follows:
* Testcase test = new Mathtest ("add") {* public void runtest () {* TestAdd (); *} *}; * Test.run ();
This is defined an internal class that covers the runtest () method. This is the most blunt way. In fact, do not parameter "add" parameters are redundant, we use the most of the following methods.
Second, use Java reflex mechanism (recently being studying this ^ _ ^, send it on:
* Testcase = New Mathtest ("TestAdd"); * Test.run ();
The "TestAdd" parameter is sent here to find and test () in the reflective mechanism, this function is exactly what is implemented in RUNTEST () overwritten in the previous method. As for how it is implemented, it will be detailed later.
Both methods were finally called the Run () method, but truly run your test method is not in this method, we have seen in the first method, TestAdd () is called in Runtest (). In fact, calling Run () is to do some statistics for the entire test process, as well as the results of the preservation test in the TestResult object, we look at Run () source code: / ** * a convenience method to Run this test, Collecting The results with a * default TestResult Object. * @see testResult * / public testResult Run () {test result = cretesult (); Run (result); Run (resul);
Public void run (test result) {result.run (this);
These statistics are implemented in the RUN (Final TestCase Test) in the TestResult, which ultimately calls the Runbare () method in TestCase through the THIS parameters:
/ ** * Runs the bare test sequence. * @Exception throwable if any any Exception is thrown * / public void Runbare () throws throwable {setup (); tryally {teardown ();}}
Everyone may be particularly familiar with setup () and teardown (), yes, this is the two options to check in the test case in Eclipse, now I know what to do, setup () is to build you Test environment, Teardown () is to do some of the end, such as if you test the class related to the database, this method is probably closing the database connection.
So I have seen it here, the focus is in Runtest (), let's analyze this method:
protected void runTest () throws Throwable {assertNotNull (fName); Method runMethod = null;. try {runMethod = getClass () getMethod (fName, null);} catch (NoSuchMethodException e) {fail ( "Method /" " fName " / "not found");} if (! Modifier.Ispublic (runmethod.getmodifiers ())) {Fail ("Method /" FName "/" Should Be PUBLIC ");}
Try {runmethod.invoke (this, new class [0]);
// the Left Code
Here is the assertNotnull (FNAME), first judge whether the method name to be called is empty, if not empty, then use the reflection mechanism to call this method, here to use the method name to find the method, that is, the front Why is it to name your test method? AssertNotnull (FNAME) method will throw Erro instead of Exception, so do not need try-catch.
The main method of TestCase here is almost over, but I have to say a little. Before watching the source code of Junit, I only had a simple app for it with Eclipse, and Eclipse helped us have done a lot of things, this is only known when looking at the source code of JUnit. For a way, every test is to initialize a TestCase instance.
I saw here today, I also wrote here. JUnit is more interesting is the structure of the entire frame. This will then say, I still read it! (^_^)
(Endlessly)
