JUnit Cookbook-Junitメニュー
J U nit Cookbook
Kent Beck, Erich Gamma
Here is a short cookbook showing you the steps you can follow in writing and organizing your own tests using JUnit.
これは簡単な説明です.JUnitで自分のテストを書いたり組織したりすることができます.
Simple Test Case
簡単なテスト例
How do you write testing code?
テストコードの作成方法
最も簡単な方法はdebuggerで式として使用することです.デバッグ式を再コンパイルせずに変更でき、実行オブジェクトが書くまで決定を待つことができます.
The simplest way is as an expression in a debugger. You can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. You can also write test expressions as statements which print to the standard output stream. Both styles of tests are limited because they require human judgment to analyze their results. Also, they don't compose nicely- you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".
JUnit tests do not require human judgment to interpret, and it is easy to run many of them at the same time. When you need to test something, here is what you do:
For example,to test that the sum of two Moneys with the same currency contains a value which is the sum of the values of the two Moneys,write:たとえば、テスト
@Test public void simpleAdd() {
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF);
assertTrue(expected.equals(result));
}
If you want to write a test similar to one you have already written, write a Fixture instead.
すでに書いたようなテストを書きたい場合は、代わりにFixtureを書きます.
Fixture
What if you have two or more tests that operate on the same or similar sets of objects?
同じオブジェクトまたは似たようなオブジェクトに2つ以上のテストがある場合.
テスト要件
Tests need to run against the background of a known set of objects. This set of objects is called a test fixture. When you are writing tests you will often find that you spend more time writing the code to set up the fixture than you do in actually testing values.
To some extent, you can make writing the fixture code easier by paying careful attention to the constructors you write. However, a much bigger savings comes from sharing fixture code. Often, you will be able to use the same fixture for several different tests. Each case will send slightly different messages or parameters to the fixture and will check for different results.
When you have a common fixture, here is what you do:
For example, to write several test cases that want to work with different combinations of 12 Swiss Francs, 14 Swiss Francs, and 28 US Dollars, first create a fixture:
例えば、12フランス通貨、14フランス通貨、28ドルの異なる協力例を書いて、まずfixtureを構築します.
public class MoneyTest {
private Money f12CHF;
private Money f14CHF;
private Money f28USD;
@Before public void setUp() {
f12CHF= new Money(12, "CHF");
f14CHF= new Money(14, "CHF");
f28USD= new Money(28, "USD");
}
}
Once you have the Fixture in place, you can write as many Test Cases as you'd like. Add as many test methods (annotated with @Test) as you'd like.
Fixtureがあれば、好きなテスト例を書くことができます.あなたの好きなテスト方法を追加します(@Test注釈で)
Running Tests
テストの実行
How do you run your tests and collect their results?
どのようにしてテストを実行し、これらの結果を関連付けますか?
Once you have tests, you'll want to run them. JUnit provides tools to define the suite to be run and to display its results. To run tests and see the results on the console, run this from a Java program:
テストがあれば、彼らを実行します.junitは、結果を実行および表示するツールを提供します.テストを実行し、コンソールで結果を表示し、Javaプロジェクトで実行します.
org.junit.runner.JUnitCore.runClasses(TestClass1.class, ...);
or this from the command line, with both your test class and junit on the classpath:
次のコマンドから、classpath環境変数にテストクラスとjunitを配置します.
java org.junit.runner.JUnitCore TestClass1.class [...other test classes...]
You make your JUnit 4 test classes accessible to a TestRunner designed to work with earlier versions of JUnit, declare a static method suite that returns a test.
Junit 4テストクラスを作成してTestRunner設計の初期のjunitバージョンにアクセスし、テストを返す静的な方法suiteを説明します.
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(Example.class);
}
Expected Exceptions
How do you verify that code throws exceptions as expected?
Verifying that code completes normally is only part of programming. Making sure the code behaves as expected in exceptional situations is part of the craft of programming too. For example:
コードが所望の異常を投げ出すことをどのように検証しますか.
検証されたコードは通常、プログラムの一部にすぎません.確信コード
new ArrayList<Object>().get(0);
This code should throw an IndexOutOfBoundsException. The @Test annotation has an optional parameter "expected"that takes as values subclasses of Throwable. If we wanted to verify that ArrayList throws the correct exception, we would write:
@Test(expected= IndexOutOfBoundsException.class) public void empty() {
new ArrayList<Object>().get(0);
}