Exception test Framework in Java JUnit uses the upper finger South _java

JUnit is a regression testing framework (regression testing framework) written by Erich Gamma and Kent Beck. JUnit testing is a programmer test, a white-box test. The Project homepage: http://www.junit.org/

When using JUnit, you write test cases primarily by inheriting the TestCase category, using the Testxxx () name to compose unit tests.

The three things you really need to write your tests with JUnit are:

1. An import statement introduces the classes under all junit.framework.*.

2. A extends statement allows your class to inherit from the TestCase.

3. A constructor that calls super (string).

Functional Class Mathtool

Package com.zj.c01;
public class Mathtool {public 
 static int gcd (int num1, int num2) { 
  int r = 0; 
  while (num2!= 0) { 
   r = num1% Num2; 
   NUM1 = num2; 
   num2 = r; 
  } 
  return NUM1 
 } 
} 

Test class Mathtooltest

Package com.zj.c01;
Import Junit.framework.TestCase; 
 
public class Mathtooltest extends TestCase {public 
 mathtooltest (String name) { 
  super (name); 
 } 
 
 public void Testgcd () { 
  assertequals (5, MATHTOOL.GCD (5)); 
 } 
 

When we use JUnit to test the method exception, the easiest way to think of it is to use Try...catch to catch the exception, and to assert the following conditions:
1. Exceptions that are actually thrown
2. Class type that throws an exception
3. Throw out the specific type of exception, general check the exception of the message attribute of the string contained in the determination
So the usual code you might write like this:

@Test public
void Testbizexception ()
{
	try{
		password.validate ("123");
		Fail ("No exception thrown.");
	}　 　 catch (Exception ex) {
		asserttrue (ex instanceof bizexception);
		Asserttrue (Ex.getmessage (). Contains ("error"));
	}
　 　　 　

The method tested here is whether the Password.validate () method throws the corresponding exception, and notice that there is no leakage in the try
Fail ("No Exception thrown.")
Line of code, or if the method being tested does not throw an exception, the use case is passed, and you expect to throw an exception.
In JUnit 4, it's not necessary to test the method exception in this way. Although this can also determine whether to perform the expected exception, but it still has drawbacks, the next will be a comparison to know that, Try...catch method, JUnit can not give you a detailed assertion failure reasons.
So what can you do to test the anomaly since JUnit 4? Use @Test (execpted=exception.class) annotation on the line, refer to the following code:

@Test (expected = bizexception.class) public
void Testbizexception ()
{
 password.validate (null); 
   
    
}　 　

   

If the test method has thrown bizexception type is the assertion of success, the @Test (expected = Bizexception.class) can only determine the type of exception, and no corresponding annotation can assert the exception of more specific information, that is not able to determine the exception thrown The message property.
Well, sometimes we throw one type of exception multiple times in a method, but the reason is different, that is, the message information for the exception is different, for example, when bizexception occurs, there are two of these exceptions:

New Bizexception ("Password must contains at least 6 letters.")
New Bizexception ("Password length less than letters")

There is a way to assert the exception message, and for this, the perfect choice since JUnit 4.7 is the following code:

@Rule public
ExpectedException expectedex = Expectedexception.none ();
@Test public
void Testbizexception () throws Invalidpasswordexception
{
	expectedex.expect (bizexception　 　 . Class);
	Expectedex.expectmessage ("required");
	Password.validate ("");
}　 　

The above code needs to focus on a few:
1. The expectedexception variable declaration @Rule annotation, it must be public
2. @Test, can not be written as a @Test (Expected=bizexception.class), or can not be properly tested, that is
The Expectedex.expectxxx () method in the @Test (Expected=bizexception.class) and test methods cannot coexist simultaneously
3. The parameters in Expectedex.expectmessage () are Matcher or subString, which means that a regular expression can be used to determine whether or not to include a substring
4. Then there is a bit heavy, the test method is written in the Expectedex.expectxxx () method, otherwise can not correctly test the exception
5. The last one is that, as long as the test method throws the exception of the test method directly, it does not affect the exception that you are concerned about.
Earlier, it is clear that the Try...catch method can be used to correctly test for anomalies, @Test (expected= ...) or @Rule compared to try...catch methods. And what will JUnit suggest for you when the test fails?
Try...catch the prompt when the test exception fails:
When there is no exception:

Java.lang.AssertionError:No exception thrown.
At Org.junit.Assert.fail (assert.java:91) at
Cc.unmi.PasswordTest.passwordLengthLessThan6LettersThrowsException (PASSWORDTEST.JAVA:20)

Wrong type of exception or wrong message for exception:

Java.lang.AssertionError: At
org.junit.Assert.fail (assert.java:91) at
org.junit.Assert.assertTrue ( assert.java:43) at
org.junit.Assert.assertTrue (assert.java:54)
at Cc.unmi.PasswordTest.passwordLengthLessThan6LettersThrowsException (passwordtest.java:22)

The help provided to us in the location error is not particularly large
Look at @Test (Expected=bizexception.class) when the test failed to prompt:

java.lang.AssertionError:Expected Exception:cc.test.BizException at
Org.junit.internal.runners.statements.ExpectException.evaluate (expectexception.java:32) at
Org.junit.rules.expectedexception$expectedexceptionstatement.evaluate (expectedexception.java:110)

@Rules ExpectedException method to test the exception, when the failure of the prompt:

Java.lang.AssertionError:
expected: (Exception with message a string containing "yes. Required "and an instance of the Java.lang.NullPointerException)
got: at
org.junit.Assert.assertThat (Assert.java : 778) at
Org.junit.Assert.assertThat (assert.java:736) at
org.junit.rules.expectedexception$ Expectedexceptionstatement.evaluate (expectedexception.java:114)

Especially @Rules the ExpectedException method, why the test failure prompt clearly. What exception is expected, what string is contained in the exception message, what type of exception is actually obtained, and what is the message in the exception. With this, you know how to fix your program as soon as you see it.