Junitは、Erich GammaとKent Beckによって書かれた回帰テストフレームワークです。 Junitテストはプログラマーテスト、つまりホワイトボックステストです。プロジェクトホームページ：http：//www.junit.org/
Junitを使用する場合、主にTestCaseカテゴリを継承してテストケースを作成し、TestXxx（）名を使用して単体テストを記述します。
Junitでテストを作成する必要がある3つのことがあります。
1.インポートステートメントは、junit.frameworkの下ですべてのクラスを導入します。*。
2。拡張ステートメントにより、クラスがテストケースから継承できるようになります。
3。Super（String）を呼び出すコンストラクター。
機能的な数学
パッケージ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; } num1を返します。 }}テストクラスMathtooltest
パッケージcom.zj.c01; import junit.framework.testcase;パブリッククラスMathtooltestはTestCaseを拡張します{public Mathtooltest（string name）{super（name）; } public void testgcd（）{assertequals（5、mathtool.gcd（10、5））; }} Junitを使用して例外をテストする場合、考えられる最も簡単な方法は、Try ... Catchを使用して例外をキャッチすることです。次の条件を主張する必要があります。
1.実際にスローされる例外2。スローされた例外のクラスタイプ3。特定のタイプの例外がスローされます。一般に、例外のメッセージ属性に含まれる文字列の決定を確認します。したがって、このような共通コードを書くことができます。
@test public void testbizexception（）{try {password.validate（ "123"）;失敗（ "例外がスローされません。"）; } catch（Exception ex）{asserttrue（ex instanceof bizexception）; asserttrue（ex.getMessage（）。contains（ "error"））; }}ここでテストする方法は、Password.validate（）メソッドが対応する例外をスローするかどうかです。試行中の失敗（ "例外が投げられない。"）はここで見逃さないことに注意してください。
それ以外の場合は、テストされているメソッドが例外をスローしない場合、このユースケースが渡され、期待するのは例外をスローすることです。
Junit 4では、このような方法の例外をテストする必要はありません。これは、予想される例外が実行されるかどうかを決定することもできますが、まだ欠点があります。あなたはそれを比較した後に知っているでしょう。 Junitは、Try ... CATCHメソッドのアサーション失敗の詳細な理由を示すことができません。
Junit 4以降、例外をテストする方法を見てみましょう。 @test（execpted = exception.class）注釈を使用するだけで、次のコードを参照してください。
@test（expection = bizexception.class）public void testbizexception（）{password.validate（null）; }
テストされている方法にbizexceptionタイプがスローされている場合、アサーションは成功します。ちなみに、@test（expects = bizexception.class）は例外のタイプを決定することのみであり、例外に関するより具体的な情報を主張する対応する注釈はありません。つまり、スローされた例外のメッセージ属性を決定することはできません。
その後、メソッドで1つのタイプの例外を複数回投げることもありますが、理由は異なります。つまり、例外のメッセージ情報が異なります。たとえば、bizexceptionが発生すると、次の2つの例外があります。
新しいbizexception（ "パスワードには少なくとも6文字が含まれている必要があります。"）new bizexception（ "パスワード長15文字未満"））
これには、例外メッセージをアサートする方法が必要です。このため、Junit 4.7以来、より完璧な選択肢を提供しました。これは次のコードです。
@rule public expectionexception equidex = equestexception.none（）; @test public void testbizexception（）throws InvalidPassWordException {expectionEx.expect（bizexception.class）; expected.ExpectMessage（ "必須"）; password.validate（ ""）; }上記のコードは次のことに焦点を合わせる必要があります。
1。@rule Annotated expectedException変数宣言、それは公開されている必要があります
2。@Testでは、@Test（expects = bizexception.class）として記述することはできません。そうしないと、正しくテストすることはできません。つまり、@test（redicted = bizexception.class）とTecquestex.expectxxx（）メソッドは、同時に共存することはできません。 3. expectionex.expectmessage（）のパラメーターはマッチャーまたはサブストリングです。つまり、正規表現を使用して、サブストリングが含まれているかどうかを判断するか判断できます。 4.もう1つは非常に重いです。Expectsex.expectxxx（）メソッドの背後にあるテスト済みの方法を書きます。そうでなければ、正しくテストできない例外5。最後のものは、テスト方法がテスト対象の方法の例外を直接スローする限り、あなたが心配している例外に影響しないということです。前述のように、Try…CATCHメソッドを使用すると、例外を正しくテストすることもできます。 @test（expects =…）または@ruleを比較することの利点は何ですか？明らかに、Junit 4が推奨する方法は簡潔で明確です。テストが失敗したときにJunitがあなたに何を促すかを見てみましょう。
テストが異常に失敗したときに取得するプロンプト：
例外がない場合：
java.lang.assertionerror：例外は投げられません。 atorg.junit.assert.fail（assert.java:91）atcc.unmi.passwordtest.passwordlengthlessthan6lettertesthrowsexcection（passwordtest.java:20）
例外タイプが間違っている場合、または例外メッセージが間違っている場合：
java.lang.assertionerror：atorg.junit.assert.fail（assert.java:91）at org.junit.assert.asserttrue（assert.java:43）at org.junit.assert.asserttrue（assert.java:54） cc.unmi.passwordtest.passwordlengthlessthan6lettersthrowsection（passwordtest.java:22）
ポジショニングエラーの上記のヘルプは特に大きくありません。 @test（expects = bizexception.class）のときにテストが失敗したときのプロンプトを見てください。
java.lang.assertionerror：期待例外：cc.test.bizexception at org.junit.internal.runners.statements.expectexception.evaluate（expectexception.java:32）
@rules expectsecceptionを使用して、例外をテストします。失敗したときのヒント：
Java.lang.AssertiONERROR：期待：（メッセージ付きの例外「はい。必須」とjava.lang.nullpointerexceptionのインスタンスを含む文字列を掲載します） org.junit.rules.expectedException $ expectedExceptionStatement.evaluate（expectionexception.java:114）
特に、@Rules HecosdExceptionメソッドは、テストが失敗した理由を明確に認識しています。予想される例、例外メッセージに含まれる文字列、実際に取得される例外の種類、例外のメッセージは何ですか。これにより、プログラムが表示されたらすぐに修正する方法がわかります。