Junit4 basic knowledge

With Java 5 annotations, JUnit 4 is lighter (in magnitude) and more flexible than previously. JUnit 4 gave up strict naming rules and inheritance layers and turned to some exciting new features. The following is a quick list of new features of JUnit 4:

• Parameter Test
• Exception Test
• Timeout Test
• Flexible firmware
• Simple Method for ignoring tests
• A new logical grouping method for testing

First, I want to explain the most important and exciting changes in JUnit 4 to prepare for introducing these and more new features in a later section.

Discard Old Rules

Before adding Java 5 annotations to JUnit 4, the framework has established two rules that are important to its running capabilities. The first rule is that JUnit explicitly requires that any method written as a logical test should begin with the word "test. Any method starting with the word, such as testusercreate, should be executed according to a well-defined test process, so as to ensure that the firmware is executed before and after the test method. The second rule: to make
JUnit identifies class objects that contain tests and requires the class itself to be extended from the testcase (or some of its derived classes) of JUnit. Tests that break any of these two rules will not run.

Introduce new methods

JUnit 4 uses Java 5 annotations to completely eliminate these two rules. Now, the class hierarchy is no longer needed, and the methods to implement the test function only need to be modified with a newly defined @ test annotation.

Simplified document

One of the useful side effects of annotations is that they clearly document the methods to be done, without having to have a deep understanding of the internal model of the framework. What is more concise and clearer than modifying the test method with @ test? This is a huge improvement for the old JUnit version. The old JUnit version requires you to be quite familiar with JUnit specifications, even if you only want to understand the contribution of each method to a complete test case.

Annotations provide a lot of help in parsing the tests that have been written, but when you see the additional help that annotations bring to the compilation of the test process, they will be more attractive.

Exception Test

In the past JUnit versions, specifying the test to throw an exception is usually a good practice. This rule is ignored only when a special exception is tested. If a test throws an exception, the Framework reports a failure. If you really want to test a special exception, @ test annotation of JUnit 4 supports an expected parameter, which indicates the exception type thrown during the test.

Timeout Test

In JUnit 4, the test case can use the timeout value as a parameter. As you can see in Listing 6, the timeout value indicates the maximum time that the test can run: if the time exceeds, the test will fail.

Ignore Test

Before JUnit 4, it was a headache to ignore bad or incomplete tests. If you want the framework to ignore a special test, you have to modify the test name and deliberately disable it from following the naming rules of the test. For example, I often put "_" before the test name to prompt that the test is not currently running. JUnit 4 introduced a comment named @ ignore, which forces the framework to ignore a special test method. You can also input a message to send your decisions to trusted developers who happen to have this ignore test.

Test firmware

Testing firmware is not a new feature of JUnit 4, but the firmware model is new and improved. In this section, I will explain why and where to use the firmware, and then introduce the differences between the old version of the inflexible firmware and the new model highlighted in JUnit 4.

Why use firmware?

The firmware advocates reuse through a contract, which ensures that the special logic runs before or after the test. In the old JUnit version, whether or not a firmware is implemented, this contract is implicit. However, JUnit 4 uses annotations to display the firmware. This means that the contract is mandatory only when you decide to use the firmware.

A contract that ensures that the firmware can run before or after the test can encode reusable logic. For example, this logic may be to initialize a class that will be tested in multiple test cases, or to populate the database before running a data dependency test. Regardless of the logic, the use of firmware ensures a more manageable test case: a test case dependent on the general logic.

It is especially convenient to run many tests that use the same logic and some or all tests fail. Instead of switching between the logic of each test setting, it is better to sum up the cause of failure in one place. In addition, if some tests pass and others fail, you can avoid checking the firmware logic as the source of all failures.

Flexibility in version 4.0

JUnit 4 uses annotations to reduce the cost of the firmware, allowing you to run the firmware once for each test, or once or not for the entire class. There are four types of firmware Annotations: There are two types of firmware for the class level and two types of firmware for the method level. At the class level, there are @ beforeclass and @ afterclass. At the method (or test) level, there are @ before and @ after.

Two new annotations

In JUnit 4, the suite semantics is replaced by two new annotations. The first one is @ runwith, designed to facilitate different runners (except the runners built into the framework) to execute a special test class. JUnit 4 is bound to a suite runner, which must be specified in the @ runwith annotation. In addition, a comment called @ suiteclasses must be provided, which uses a list of classes intended to represent the test suite as parameters.

Ant and JUnit 4

Now ant and JUnit have been a perfect combination for a long time, and many developers expect that this relationship will only become better after JUnit 4 is introduced. But the result is that there are some problems. If you are running any version earlier than ant 1.7, you cannot easily run the ready-made JUnit 4 test. That's not to say that you cannot run these tests-but not immediately.

Parameter Test

Occasionally, the business logic of an application requires you to write many tests that are not quantitative to ensure robustness. In versions earlier than JUnit, this scenario is inconvenient because the parameter groups of methods in a test are different, meaning that a test case should be compiled for each individual group.

JUnit 4 introduces an outstanding new feature that allows you to create a common test that is supplied by parameter values. The result is that you can create a single test case and run it multiple times-run it once for each parameter you have created.

Parameter conciseness

To create a parameter test in JUnit 4, you only need to perform the following five steps:

1. Create a universal test without parameters.
2. Create a static feeder method that returns the collection type and annotate it with @ parameter.
3. Creates class members for the parameter types required by the general method defined in step 1.
4. Create a constructor that holds these parameter types and associate these parameter types with the class members defined in step 3.
5. Use the @ runwith annotation to specify the test case to run with the parameterized class.

 

Address: http://www.ibm.com/developerworks/cn/education/java/j-junit4/section8.html