カスタマイズ > カスタマイズの自動化の検証に関するガイドライン > テストのオーサリング > ユニットテストのガイドラインとベストプラクティス
ユニットテストのガイドラインとベストプラクティス
このセクションでは、ユニットテストのガイドラインとベストプラクティスについて概要を説明します。
ユニットテストは、メソッドサーバーが動作していない状態で実行することが可能なテストです。
開発マシンでローカルにユニットテストを実施する際には、メソッドサーバーが停止した状態で正常に実行されるようにしてください。
すべてのユニットテスト名が ****Test.java である必要があります。
互いに独立したテストケースを作成します。
ユニットテストを通じてすべてのパスをカバーすることを目指します。
本番環境に近いテストデータを使用します。
ユニットテストがメモリ内で完全に実行されるようにしてください。たとえば、HTTP リクエストを行うユニットテスト、データベースにアクセスするユニットテスト、ファイルシステムから読み取りを行うユニットテストを作成しないでください。
ユニットテストをスキップしないでください。
ユニットテストの各メソッドがアサーションを 1 つだけ実行することを目指します。
規則に従って、テスト対象のメソッドと条件から成る名前をユニットテストに付けます。たとえば、テスト対象のメソッドが 'encode(bytes[])' であり、渡すことができるすべてのタイプの入力 (Null、空、バイト数が少なすぎる、バイト数が多すぎるなど) をテストするテストケースがある場合、これらのユースケースごとに個別のテストを作成します。
encode_nullBytes
encode_emptyBytes
encode_tooFewBytes
encode_tooManyBytes
encode_rightNumBytes または encode_validBytes
テストクラスが、テスト中の本番環境クラスと同じ Java パッケージに存在するようにします。
テストコードが本番環境コードから分離されているようにします。
ユニットテストクラスのコンストラクタで初期化しないでください。代わりに @Before メソッドを使用します。
ユニットテストで Thread.sleep を使用しないでください。
次のように、最適なアサーションメソッドを使用します。
assertEquals(true, classUnderTest.methodUnderTest()) ではなく assertTrue(classUnderTest.methodUnderTest()) を使用します。
assertTrue(classUnderTest.methodUnderTest().equals(expectedReturnValue)) ではなく assertEquals(expectedReturnValue, classUnderTest.methodUnderTest()) を使用します。
コレクションのサイズとコレクションの各メンバーをアサーションするのではなく、assertEquals(expectedCollection, classUnderTest.getCollection()) を使用します。
アサーションパラメータを適切な順序で配置します。JUnit のアサーションへのパラメータは次のとおりです。
a. expected
b. actual
assertEquals (actual, expected) ではなく assertEquals (expected, actual) を使用します。
テストに合格するためにだけ存在する独自の catch ブロックを作成しないでください。
// Don't do this - it's not necessary to write the try/catch!
@Test
public void foo_nine()
{
boolean wasExceptionThrown = false;
try
{
new Foo().foo(9);
}
catch (final IOException e)
{
wasExceptionThrown = true;
}
assertTrue(wasExceptionThrown);
}
// Do this instead
@Test(expected = IOException.class)
public void foo_nine() throws Exception
{
new Foo().foo(9);
}
テストクラスでは、メソッドが特定のタイプの例外をスローすることを宣言しないでください。
final class Foo
{
int foo(int i) throws IOException;
}
// Don't do this - the throws clause is too specific!
@Test
public void foo_seven() throws IOException
{
assertEquals(3, new Foo().foo(7));
}
代わりに、テストメソッドが任意の例外をスローできることを宣言します。
// Do this instead
@Test
public void foo_seven() throws Exception
{
assertEquals(3, new Foo().foo(7));
}
テストの作成中は適切なアノテーションを使用します。
テスト中のメソッドが別のクラスの別のメソッドを呼び出した場合、その '呼び出された' メソッドがモッキングの候補になる可能性があります。'呼び出された' メソッドをモッキングせずに、テストが問題なく正常に実行された場合、モッキングは不要である可能性があります。モッキングが必要になる事例としては、'呼び出された' メソッドがオペレーションを実行するためにメソッドサーバーを必要とする場合が挙げられます。
クラスのモッキングは慎重に使用してください。クラスがモッキングされると、通常は 1 回のテストの間、既存のメソッドまたはコンストラクタの元の実装が一時的にモック実装に置き換えられます。
これは役に立ちましたか?