JBUILDER2005 Unit Test JUnit Framework _jsp programming

A simple framework

JUnit is an open source testing framework developed by Erich Gamma and Kent Beck, and JBuilder integrates the framework and expands on it. The reason why JUnit is popular and respected by the vast number of developers is that it is real and powerful, and the second is because it is simple. A product or framework to be able to have vitality, it is best to have such characteristics.

Simply speaking, this framework provides a number of assertion (assert) methods that allow you to set the rules for testing, such as assertequals (), Assertnull (), Assertnotsame (), Asserttrue (), and so on. A test case includes multiple assertions, and when the test case is run, the JUnit runtime reports which assertions are not passed, and the developer can get to the bottom of it. The traditional test method needs to print the process information to the console or log with statements such as SYSTEM.OUT.PRINTLN (), and the developer observes the output to determine whether it is correct, and now this "observation" work is done by the JUnit assertxxx () method is automatically completed.

The JUnit test framework class structure is simple, consisting mainly of 3 classes, whose class diagram relationships are shown in the following illustration:


Wrong figure! Text with no specified style in the document. JUnit Test Framework class structure

junit.framework.test: Test interface.

junit.framework.testcase: Test case classes, test case classes for business classes only need to inherit this TestCase, write several public void Testxxx () methods based on the situation, and pass assertyyy () in the method It's OK to customize a few test rules.

junit.framework.testsuite: Test suite class, which allows you to bundle multiple test case classes together or bundle another test suite.
　　 test firmware (Fixture)

A test case can contain several testxxx () test methods, test cases test the correctness of one or more class API interfaces, of course, when invoking class APIs, you need to create the object of this class and some associated objects in advance, which is called the Test firmware (Fixture), which is equivalent to the test case "Work object."

As we said earlier, a test case class can contain multiple Testxxx () methods, and each test method corresponds to an instance of a test case class at run time. Of course, you can declare and instantiate instances of business classes in specific testxxx () methods, and then destroy them after the test is complete. However, you will have to repeat the code in each testxxx () method, because the TestCase instance is run with the following steps:

1. Create an instance of a test case.

2. Invoke the Setup () method to perform some initialization work.

3. Run the Testxxx () test method.

4. Call the Teardown () method to perform the task of destroying the object.

If there are multiple testxxx () methods in the test case class, and they all need to use the same set of objects, we can instantiate the set of objects in Setup () and destroy them in teardown (). To write a test firmware, follow these steps:

1. Create subclasses of the TestCase class.

2. Declare the objects used by several tests in a subclass.

3. Override the Setup () method to instantiate the objects in the method.

4. Overwrite the teardown () method to release resources for these objects.

The following is a simple test firmware:

Code Listing Error! Text with no specified style in the document. Testing the Firmware

1. Public class Moneytest extends TestCase
2. {
3. Private Money F12CHF;//12 Franc
4. Private Money F14CHF; 14 Swiss francs
5. Private Money F28USD; 28 United States dollar
6. protected void SetUp () {
7. F12chf= New Money ("CHF");
8. F14chf= New Money ("CHF");
9. F28usd= New Money ("USD");
10.}
protected void Teardown () {}
12.}


Line 3rd to 5th declares 3 Money class objects (test firmware), instantiates the 3 objects (line 7th to 9th) in the Setup () method, and does nothing in teardown () because they can be recycled directly by garbage.

　　 test Case (TestCase)

With the test firmware, you can begin writing test methods for test cases. Of course, you can write test case methods directly without testing the firmware. Here we add the test case Method Testmoneybag () based on the test firmware, and the code looks like this:

Code Listing Error! Text with no specified style in the document. Test Case methods

1. Public class Moneytest extends TestCase
2. {
3. Private Money F12CHF;//12 Franc
4. Private Money F14CHF; 14 Swiss francs
5. Private Money F28USD; 28 United States dollar
6. protected void SetUp () {
7. F12chf= New Money ("CHF");
8. F14chf= New Money ("CHF");
9. F28usd= New Money ("USD");
10.}
One. public void Testmoneybag ()
12. {
Money bag[]= {F26CHF, F28USD};
Moneybag expected= new Moneybag (bag);
Assertequals (expected, F12chf.add (F28usd.add (F14CHF));
16.}
protected void Teardown () {}
18.}

Test methods must be prefixed with test and must be public void, and the runtime finds these test case methods for the reflection lookup rule. You can include multiple assertyyy () methods in one method, and each assertyyy () method is a test rule. The assertyyy () assertion method, like line 15th, is a test rule that tests Money's add () method and Moneybag class correctness.

You can add multiple public void testxxx () methods in Moneytest, and the runtime generates a test case instance for each method, which runs separately.

test Suite (TestSuite)

If you can run only one test case at a time, you're stuck in the dilemma of the traditional test we talked about: Manually running test cases by hand, and the test suite is dedicated to solving the problem. It assembles multiple test cases into a test suite through the Testsuite object, and the test suite runs in batches. The special point is that you can add a test suite to another test suite, just like a small basket in a big basket into a suitcase.

The test suite class is also implemented by inheriting the TestCase class, except that it provides a public static test suite () static method in which multiple test cases are bundled together. A typical test suite code looks like this:

Code Listing Error! Text with no specified style in the document. Test suite

1. Public class Moneytestsuite extends TestCase
2. {
3. Public TestSuite1 (String s)
4. {
5. Super (s);
6.}
7. public static Test Suite ()
8. {
9. TestSuite Suite = new TestSuite ();
Suite.addtestsuite (Moneytest.class);
Suite.addtestsuite (Moneybag.class);
return suite;
13.}
14.}

Declare and instantiate a testsuite in line 9th and add a test case to line 10th and 11. You can add a suite through the Suite.addtest (Test t) method. Running this suite will automatically run the test methods for all test cases.

　 Test Run

JUnit provides 3 standard test runs for running these test cases or test suites, and the 3 test runs are:

junit.textui.testrunner: Text test run.
Junit.awtui.testrunner: Test run using the AWT component interface.
Junit.swingui.testrunner: A test run that uses the Swing component interface.

The following is a test run based on the AWT component, as shown in the following illustration:

Wrong figure! Text with no specified style in the document. AWT Test Run

· Test class Name: Specifies the testing case class and test suite class.

• A progress bar: represents the execution progress of a test run, with the correct, wrong, and failed test statistics under the progress bar.

· Error and failures: Lists of test errors and failures are listed, and when you click one of these options, JUnit lists errors and trails at the bottom of the window.

Tips:

JBuilder provides a convenient way to run test cases and test suite classes, and you can call directly by clicking the right mouse button. In addition, JBuilder provides a jbtestrunner test run that is comparable in functionality and ease of use to the test run provided by JUnit. JBuilder supports the two test runs that JUnit provides: Junit.textui.TestRunner and Junit.swingui.TestRunner.