20

Mockito を使用した単体テストでは、それNullPointerExceptionがスローされなかったことを確認したいと思います。

public void testNPENotThrown{
    Calling calling= Mock(Calling.class);
    testClass.setInner(calling);
    testClass.setThrow(true);

    testClass.testMethod();

    verify(calling, never()).method();
}

私のテストtestClassでは、オブジェクトとプロパティを設定しCallingて、メソッドがNullPointerException.

Calling.method() が呼び出されないことを確認します。

public void testMethod(){
    if(throw) {
        throw new NullPointerException();
    }

    calling.method();
}

がスローされるため、失敗したテストが必要NullPointerExceptionです。次に、これを修正するコードを書きたいと思います。

私が気付いたのは、例外がテストメソッドでスローされることは決してないため、テストは常にパスするということです。

4

4 に答える 4

6

あなたが間違っていることを理解していない場合は、次のようなものが必要です。

@Test(expected = NullPointerException.class)
public void testNPENotThrown {
    Calling calling= Mock(Calling .class);
    testClass.setInner(calling);
    testClass.setThrow(true);

    testClass.testMethod();

    verify(calling, never()).method();
    Assert.fail("No NPE");
}

しかし、「NPENotThrown」という名前のテストでは、次のようなテストが期待されます。

public void testNPENotThrown {
    Calling calling= Mock(Calling .class);
    testClass.setInner(calling);
    testClass.setThrow(true);

    testClass.testMethod();
    try {
        verify(calling, never()).method();
        Assert.assertTrue(Boolean.TRUE);
    } catch(NullPointerException ex) {
        Assert.fail(ex.getMessage());
    }
}
于 2013-07-02T13:02:08.357 に答える
2

別のアプローチとして、代わりに try/catch を使用することもできます。少し乱雑ですが、私が理解していることから、このテストはTDD用であるため、いずれにせよ短命になるでしょう:

@Test
public void testNPENotThrown{
  Calling calling= Mock(Calling.class);
  testClass.setInner(calling);
  testClass.setThrow(true);

  try{
    testClass.testMethod();
    fail("NPE not thrown");
  }catch (NullPointerException e){
    //expected behaviour
  }
}

編集：これを書いたとき、私は急いでいました。「このテストはTDD用であるため、とにかく短命になる」というのは、このテストをすぐに修正するコードを書くつもりであり、将来的にNullPointerExceptionがスローされることはないと言っているということです。次に、テストを削除することもできます。したがって、美しいテストを書くのに多くの時間を費やす価値はおそらくないでしょう (したがって、私の提案:-))

より一般的に：

(たとえば) メソッドの戻り値が null ではないことをアサートするテストから始めることは確立された TDD 原則であり、NullPointerException (NPE) をチェックすることは、これに対処するための 1 つの可能な方法です。ただし、本番コードには、おそらく NPE がスローされるフローはありません。null をチェックしてから、賢明なことをするつもりだと思います。実際には発生することはありませんが、NPE がスローされていないことを確認するため、この特定のテストはその時点で冗長になります。次に、null が検出されたときに何が起こるかを検証するテストに置き換えることができます。たとえば、NullObject を返すか、他の種類の例外をスローするなど、適切なものは何でもかまいません。

もちろん、冗長なテストを削除する必要はありませんが、削除しないとそのまま残り、各ビルドがわずかに遅くなり、テストを読む各開発者が不思議に思うことになります。「うーん、NPE ですか? このコードは NPE をスローできませんか?」. テストクラスにこのような冗長なテストがたくさんあるTDDコードをたくさん見てきました。時間が許せば、テストを頻繁に見直すことをお勧めします。

于 2013-07-02T13:08:47.403 に答える
0

通常、各テスト ケースは新しいインスタンスで実行されるため、インスタンス変数を設定しても役に立ちません。そうthrowでない場合は、' ' 変数を静的にします。

于 2013-07-02T13:06:18.800 に答える