Junit (2) Small trial sledgehammer

We continue to analyze the examples in the primary article. In the introductory chapter we use Eclipse to automatically generate a test framework, in this article, we will carefully analyze the test framework of each of the details, know it more to know why, in order to become more proficient in the application of JUNIT4.

A. Contains the necessary package

The JUNIT4 framework is used in the test class, and the package is naturally included in the corresponding package. One of the most important package is org.junit.*. After it is included, most of the features are there. There is also a word that is very important "import static org.junit.assert.*;", we use a series of assertequals methods when testing from this package. Note that this is a static inclusion (static), which is a new feature added in JDK5. In other words, Assertequals is a series of static methods in an Assert class, and is generally used in an assert manner. Assertequals (), but with static inclusion, the preceding class name can be omitted and used more conveniently.

II. Declaration of the Test class

It is noted that our test class is a separate class, without any parent class. The name of the test class can also be arbitrarily named, without any limitations. So we cannot tell by the declaration of a class that it is not a test class, but that it differs from the ordinary class in its declaration of methods inside it, which we will then talk about.

Iii. creating an object to be tested

Which class you want to test, you'll first create an object of that class. As the code in the previous article:

Private Staticcalculator calculator =newcalculator ();

In order to test the calculator class, we must create a calculator object.

Iv. Declaration of test methods

In a test class, not every method is used for testing, and you must use "callout" to clearly indicate which is the test method. "Labeling" is also a new feature of JDK5, which is very appropriate here. As we can see, there are @before, @Test, @Ignore and so on before some methods, and these are the annotations, which begin with an "@". These annotations are JUNIT4 customized and it is important to master the meaning of these annotations.

Five, write a simple test method

First, you will use the @test callout in front of the method to indicate that this is a test method. The declaration of a method has the following requirements: The name can be arbitrarily taken without any restrictions, but the return value must be void and cannot have any arguments. If these rules are violated, an exception is thrown at run time. As for what to write in the method, it depends on what you need to test. Like what:

@Test

Public Voidtestadd () ... {

Calculator.add (2);

Calculator.add (3);

Assertequals (5, Calculator.getresult ());

}

We want to test the "addition" function when the correct, in the test method called several times the Add function, the initial value of 0, plus 2, plus 3, we expect the result should be 5. If the final actual result is also 5, then the Add method is correct, and the reverse means it is wrong. Assertequals (5, Calculator.getresult ()); Is to determine whether the expected results and actual results are equal, the first parameter fills in the expected result, the second parameter fills in the actual result, that is, the results obtained by the calculation. When this is done, JUnit automatically tests and feeds the test results back to the user.

Vi. ignoring testing for some unfinished methods

If you do a good job planning before you write the program, then what is the function should be fixed. Therefore, even if the method is not yet complete, his specific functionality is deterministic, which means that you can write test cases for him. However, if you have finished writing the test case for the method, but the method is not yet complete, then the test must be "failed". This failure is different from real failure, so JUnit provides a way to differentiate them by adding a @ignore callout to the test function, meaning that "some methods have not been completed and are not currently participating in the test." In this case, the test results will prompt you to have several tests ignored, not failures. Once you have completed the corresponding function, just delete the @ignore annotation and you can perform the normal test.

Vii. Fixture (translated as "fixed code snippet")

The meaning of Fixture is "code that must be called at certain stages". For example, the above test, because only a calculator object is declared, his initial value is 0, but after testing the addition operation, his value is not 0, and then test the subtraction operation, it is necessary to consider the results of the last addition operation. This is definitely a bad design! We very much hope that each test is independent and does not have any coupling degree. Therefore, it is necessary for us to perform a "undo" operation on the Calculator object before executing each test to eliminate the impact of other tests. Therefore, "code that must be executed before any test execution" is a fixture, and we use @before to label it as shown in the previous example:

@Before

public void SetUp () throws Exception ... {

Calculator.clear ();

}

There is no need for @test labeling here, because this is not a test, but a fixture. Similarly, if the "finishing touches required after any test execution" is also a fixture, use @after to annotate. Because this example is relatively simple, this function is not used.

Some of the basics of JUNIT4 are introduced here, and there are some more flexible uses in this series of high-level articles to introduce you!

First, advanced fixture

In the previous article we introduced two fixture annotations, namely @before and @after, to see if they are suitable for the following functions: one class is responsible for reading and writing large files (more than 500 megabytes), and each of his methods is manipulating the files. In other words, before invoking each method, we have to open a large file and read the contents of the file, which is definitely a time-consuming operation. If we use @before and @after, then each test will have to read the file once, efficiency and low. What we want here is to read the file at the start of all tests, release the file after all the tests are finished, and not read the file every time. The JUnit authors clearly consider this issue, which gives @beforeclass and @AfterClass two fixture to help us achieve this function. As can be seen from the name, using the functions labeled in these two fixture, only the @BeforeClass method is executed when the test case is initialized, and after all the tests have been executed, the @afterclass is performed to finish the work. Note here that only one method per test class can be labeled as @BeforeClass or @AfterClass, and that the method must be public and static.

Second, time-limited testing

Remember the example I gave in my introductory article, the function that squared root has a bug, is a dead loop:

Public Voidsquareroot (INTN) ... {

for (;;);//bug: Dead Loop

}

If you encounter a dead loop during testing, you will never smile on your face. Therefore, for those whose logic is very complex, the loop nesting is relatively deep, there is a possibility of a dead loop, so it is necessary to take some precautions. Time-limited testing is a good solution. We set an execution time for these test functions, more than that, they will be forcibly terminated by the system, and the system will report to you the reason for the end of the function is because of the timeout, so you can find these bugs. To do this, you only need to add a parameter to the @test callout, and the code is as follows:

@Test (timeout = 1000)

Public Voidsquareroot () ... {

Calculator.squareroot (4);

Assertequals (2, Calculator.getresult ());

}

The timeout parameter indicates the time you want to set, in milliseconds, so 1000 represents 1 seconds.

Third, test the exception

Exception handling in Java is also a priority, so you will often write some functions that need to throw exceptions. So, if you think a function should throw an exception, but it's not thrown, does that count as a bug? This is certainly a bug, and JUnit also takes this into account to help us find this bug. For example, we write the Calculator class has the division function, if the divisor is a 0, then must throw "except 0 exception". Therefore, it is necessary for us to test these. The code is as follows:

@Test (expected = arithmeticexception.class)

public void DivideByZero () ... {

Calculator.divide (0);

}

As shown in the code above, we need to use the expected property of the @test callout to pass the exception we want to test to him so that the JUnit framework will automatically help us detect if the exception we specified is thrown.

Four, Runner (running device)

Have you ever thought about this question, how does the framework run your code when you submit the test code to the JUnit framework? The answer is--runner. There are many Runner in JUnit, they are responsible for invoking your test code, each Runner has its own special features, and you need to choose different Runner to run your test code as needed. Perhaps you will find it strange that we have written so many tests before, and have not explicitly specified a runner ah? This is because there is a default runner in JUnit, and if you do not specify it, the system automatically uses the default runner to run your code. In other words, the following two paragraphs of code mean exactly the same:

Import Org.junit.internal.runners.TestClassRunner;

Import Org.junit.runner.RunWith;

The system default Testclassrunner is used, exactly as in the following code

public class calculatortest ... {

...

}

@RunWith (Testclassrunner.class)

public class calculatortest ... {

...

}

As you can see from the above example, to specify a runner, you need to use the @runwith callout and pass the runner you specify as a parameter to it. Another thing to note is that the @RunWith is used to modify the class, not to modify the function. All functions in this class are called by this runner whenever a runner is specified for a class. Finally, do not forget to include the appropriate package, the above example is very clear. Next, I'll show you the unique features of other runner.

Wordend Related reading:

Five, parametric test

You may have encountered such a function, its parameters have many special values, or his parameters are divided into a number of areas. For example, a function to evaluate test scores, the return value is "good, good, general, pass, fail", so you write the test, at least to write 5 tests, the 5 is included in the situation, this is really a very troublesome thing. We also use our previous example to test the "calculate the square of a number" this function, for the moment divided into three categories: positive, 0, negative. The test code is as follows:

　

　Import Org.junit.AfterClass;　　Import Org.junit.Before;　　Import Org.junit.BeforeClass;　　Import Org.junit.Test;　　Import static org.junit.assert.*; public class advancedtest ...　　{private static Calculator Calculator = new Calculator (); @Before public void Clearcalculator () ...　　{calculator.clear (); } @Test public void Square1 () ...　　{Calculator.square (2);　　Assertequals (4, Calculator.getresult ()); } @Test public void Square2 () ...　　{calculator.square (0);　　Assertequals (0, Calculator.getresult ()); } @Test public void Square3 () ...　　{Calculator.square (-3);　　Assertequals (9, Calculator.getresult ()); In order to simplify similar tests, JUNIT4 puts forward the concept of "parametric testing", writing only one test function, passing in several cases as parameters, and testing them once.　　The code is as follows: import static org.junit.Assert.assertEquals;　　Import Org.junit.Test;　　Import Org.junit.runner.RunWith;　　Import org.junit.runners.Parameterized;　　Import Org.junit.runners.Parameterized.Parameters;　　Import Java.util.Arrays;　　Import java.util.Collection; @RunWith (parameterized.class) public class squaretest..　　{private static Calculator Calculator = new Calculator ();　　private int param;　　private int result; @Parameters public static Collection data () ... {return arrays.aslist (new object[][] ... {　　... {2, 4}, ... {0, 0}, ...　　{-3, 9},}); }//constructor to initialize the variable

Copyright notice: I feel like I'm doing a good job. I hope you can move your mouse and keyboard for me to order a praise or give me a comment, under the Grateful!_____________________________________________________ __ Welcome reprint, in the hope that you reprint at the same time, add the original address, thank you with

Junit (2) Small trial sledgehammer