您如何断言在JUnit 4测试中抛出了某个异常?


1998

如何惯用JUnit4来测试某些代码引发异常?

虽然我当然可以做这样的事情:

@Test
public void testFooThrowsIndexOutOfBoundsException() {
  boolean thrown = false;

  try {
    foo.doStuff();
  } catch (IndexOutOfBoundsException e) {
    thrown = true;
  }

  assertTrue(thrown);
}

我记得在这种情况下,有一个批注或一个Assert.xyz或那么杂乱无章的JUnit东西。


21
任何其他方法的问题在于,一旦抛出异常,它们总是会终止测试。另一方面,我通常仍想org.mockito.Mockito.verify使用各种参数进行调用,以确保在引发异常之前发生了某些事情(例如,使用正确的参数调用了logger服务)。
ZeroOne 2013年


6
@ZeroOne-为此,我将进行两种不同的测试-一种用于测试异常,另一种用于验证与您的模拟的交互。
tddmonkey 2014年

使用JUnit 5可以做到这一点,我在下面更新了我的答案。
迪利尼·拉贾帕克莎(Dilini Rajapaksha),

Answers:


2360

这取决于JUnit版本和使用的断言库。

最初的答案JUnit <= 4.12是:

@Test(expected = IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {

    ArrayList emptyList = new ArrayList();
    Object o = emptyList.get(0);

}

虽然回答https://stackoverflow.com/a/31826781/2986984对于JUnit <= 4.12有更多选项。

参考:


66
如果您只希望在代码中的某个地方(而不是像这样的毯子)遇到异常,那么这段代码将无法工作。
Oh Chin Boon

4
@skaffman这不适用于由org.junit.experimental.theories.Theory运行的org.junit.experimental.theories.Theory
Artem Oboturov 2012年

74
Roy Osherove不鼓励在单元测试的领域中进行此类异常测试,因为异常可能在测试内部的任何地方,而不仅是在被测单元内部。
凯文·威特克

21
我不同意@ Kiview / Roy Osherove。我认为,测试应该针对行为,而不是针对实施。通过测试特定方法会引发错误,您可以将测试直接与实现联系在一起。我认为用上述方法测试可以提供更有价值的测试。我要补充的一点是,在这种情况下,我将测试自定义异常,以使我知道自己收到了我真正想要的异常。
nickbdyer's

5
都不行 我想测试该类的行为。重要的是,如果我尝试检索不存在的内容,则会出现异常。数据结构是ArrayList响应的事实get()是无关紧要的。如果将来选择迁移到原始数组,则必须更改此测试实现。数据结构应该是隐藏的,以便测试可以将重点放在的行为上。
nickbdyer '16

1315

编辑:现在已经发布了JUnit 5和JUnit 4.13,最好的选择是使用Assertions.assertThrows() (对于JUnit 5)和Assert.assertThrows()(对于JUnit 4.13)。请参阅我的其他答案以获取详细信息。

如果尚未迁移到JUnit 5,但可以使用JUnit 4.7,则可以使用ExpectedExceptionRule:

public class FooTest {
  @Rule
  public final ExpectedException exception = ExpectedException.none();

  @Test
  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();

    exception.expect(IndexOutOfBoundsException.class);
    foo.doStuff();
  }
}

这要好得多,@Test(expected=IndexOutOfBoundsException.class)因为如果IndexOutOfBoundsException之前抛出测试,测试将失败foo.doStuff()

请参见本文的详细信息


14
@skaffman-如果我正确地理解了这一点,它看起来就像是exception.expect仅在一个测试中应用,而不是在整个类中应用。
bacar 2012年

5
如果我们希望引发的异常是一个已检查的异常,是否应该添加throw或try-catch或以其他方式测试这种情况?
Mohammad Jafar Mashhadi

5
@MartinTrummer在foo.doStuff()之后不应运行任何代码,因为会引发异常并退出该方法。无论如何,将代码放在预期的异常之后(最后关闭资源除外)无济于事,因为如果引发异常,则永远不应执行该代码。
杰森·汤普森

9
这是最好的方法。与skaffman的解决方案相比,这里有两个优点。首先,ExpectedException该类具有匹配异常消息的方法,甚至可以编写依赖于异常类的自己的匹配器。其次,您可以在期望引发异常的代码行之前立即设置期望值-这意味着,如果错误的代码行引发异常,则测试将失败。而用skaffman的解决方案则无法做到这一点。
达伍德·伊本·卡里姆

5
@MJafarMash如果选中了您希望引发的异常,则可以将该异常添加到测试方法的throws子句中。在测试声明为引发已检查异常的方法时,即使在特定测试用例中未触发该异常,您也可以执行相同的操作。
NamshubWriter 2015年

471

请小心使用预期的异常,因为它仅断言该方法引发了该异常,而不是测试中的特定代码行

我倾向于将其用于测试参数验证,因为此类方法通常非常简单,但最好将更复杂的测试用于:

try {
    methodThatShouldThrow();
    fail( "My method didn't throw when I expected it to" );
} catch (MyException expectedException) {
}

运用判断。


95
也许我是老学校,但我还是喜欢这个。它还为我提供了一个测试异常本身的地方:有时我在某些值的getter异常中使用异常,或者我可能只是在消息中查找特定值(例如,在消息“无法识别的代码'xyz'中寻找“ xyz” ”)。
罗德尼·吉泽尔

3
我认为NamshubWriter的方法可以为您提供两全其美的体验。
艾迪(Eddie)

4
使用ExpectedException,您可以调用N exception.expect每个方法来进行测试,例如:exception.expect(IndexOutOfBoundsException.class); foo.doStuff1(); exception.expect(IndexOutOfBoundsException.class); foo.doStuff2(); exception.expect(IndexOutOfBoundsException.class); foo.doStuff3();
user1154664

10
@ user1154664实际上,你不能。使用ExpectedException,您只能测试一个方法引发异常,因为调用该方法时,测试将因为引发了预期的异常而停止执行!
NamshubWriter 2014年

2
您的第一句话不是真的。使用时ExpectedException,通常要做的是在期望引发异常的行之前立即设置期望值。这样,如果较早的行抛出异常,它将不会触发规则,并且测试将失败。
达伍德·伊本·卡里姆

212

如前所述,在JUnit中有许多处理异常的方法。但是对于Java 8,还有另一个:使用Lambda表达式。使用Lambda表达式,我们可以实现如下语法:

@Test
public void verifiesTypeAndMessage() {
    assertThrown(new DummyService()::someMethod)
            .isInstanceOf(RuntimeException.class)
            .hasMessage("Runtime exception occurred")
            .hasMessageStartingWith("Runtime")
            .hasMessageEndingWith("occurred")
            .hasMessageContaining("exception")
            .hasNoCause();
}

assertThrown接受一个功能接口,可以使用lambda表达式,方法引用或构造函数引用创建其实例。assertThrown接受该接口将期望并准备处理异常。

这是相对简单但功能强大的技术。

看看描述此技术的博客文章:http : //blog.codeleak.pl/2014/07/junit-testing-exception-with-java-8-and-lambda-expressions.html

可以在这里找到源代码:https : //github.com/kolorobot/unit-testing-demo/tree/master/src/test/java/com/github/kolorobot/exceptions/java8

披露:我是博客和项目的作者。


2
我喜欢这个解决方案,但是可以从Maven仓库下载吗?
Selwyn

@Airduster在Maven上可用的这一想法的一种实现是stefanbirkner.github.io/vallado
NamshubWriter 2015年

6
@CristianoFontes将为JUnit 4.13定义此API的一个简单版本。见github.com/junit-team/junit/commit/...
NamshubWriter

@RafalBorowiec从技术上讲new DummyService()::someMethod是a MethodHandle,但是这种方法对lambda表达式同样有效。
安迪

@NamshubWriter,似乎JUnit的4.13赞成的junit 5的被遗弃:stackoverflow.com/questions/156503/...
Vadzim

154

在junit中,有四种测试异常的方法。

junit5.x

  • 对于junit5.x,您可以使用assertThrows以下方法

    @Test
    public void testFooThrowsIndexOutOfBoundsException() {
        Throwable exception = assertThrows(IndexOutOfBoundsException.class, () -> foo.doStuff());
        assertEquals("expected messages", exception.getMessage());
    }

junit4.x

  • 对于junit4.x,请使用测试注解的可选“ expected”属性

    @Test(expected = IndexOutOfBoundsException.class)
    public void testFooThrowsIndexOutOfBoundsException() {
        foo.doStuff();
    }
  • 对于junit4.x,请使用ExpectedException规则

    public class XxxTest {
        @Rule
        public ExpectedException thrown = ExpectedException.none();
    
        @Test
        public void testFooThrowsIndexOutOfBoundsException() {
            thrown.expect(IndexOutOfBoundsException.class)
            //you can test the exception message like
            thrown.expectMessage("expected messages");
            foo.doStuff();
        }
    }
  • 您还可以使用在junit 3框架下广泛使用的经典try / catch方法

    @Test
    public void testFooThrowsIndexOutOfBoundsException() {
        try {
            foo.doStuff();
            fail("expected exception was not occured.");
        } catch(IndexOutOfBoundsException e) {
            //if execution reaches here, 
            //it indicates this exception was occured.
            //so we need not handle it.
        }
    }
  • 所以

    • 如果您喜欢junit 5,那么您应该喜欢第一个
    • 当您只想测试异常类型时,使用第二种方法
    • 当您想进一步测试异常消息时,使用前两个和后两个
    • 如果您使用junit 3,则首选第4个
  • 有关更多信息,您可以阅读此文档junit5用户指南以了解详细信息。


6
对我来说,这是最好的答案,它非常清楚地涵盖了所有方面,谢谢!我个人甚至在使用Junit4的情况下仍继续使用第3个选项,以提高可读性,为避免出现空的捕获块,您还可以捕获Throwable和assert类型的e
Nicolas Cornette

是否可以使用ExpectedException期望检查异常?
miuser

所有这些都是前三个答案的累加。IMO,如果它没有添加任何新内容,那么甚至不应该发布此答案。只需回答代表的一个(受欢迎的问题)即可。真没用。
保罗·萨姆索塔

当然,因为您可以将任何派生自类型Trowable的方法传递给method ExpectedException.expect。请看它的签名。@miuser
walsh

116

tl; dr

  • JDK8之后:使用AssertJ或自定义lambda来声明异常行为。

  • JDK8之前的版本:我将推荐旧的好try- catch块。(不要忘记fail()在该catch块之前添加一个断言

无论是Junit 4还是JUnit 5。

长话

可以自己编写一个自己执行的操作 try - catch阻止或使用JUnit工具(@Test(expected = ...)@Rule ExpectedExceptionJUnit规则功能)。

但是这些方法并不那么优雅,并且在可读性方面与其他工具没有很好的融合。而且,JUnit工具确实存在一些陷阱。

  1. try- catch块,你必须写周围的测试行为块,写在catch块的断言,这可能是罚款,但很多人觉得这种风格中断测试的阅读流程。另外,您需要Assert.fail在代码try块的末尾写一个。否则,测试可能会遗漏断言的某一方面;PMDfindbugsSonar会发现此类问题。

  2. @Test(expected = ...)功能很有趣,因为您可以编写更少的代码,然后编写此测试的代码据说不那么容易出错。但是在某些领域缺少这种方法。

    • 如果测试需要检查有关异常的其他内容,例如原因或消息(好的异常消息非常重要,那么具有精确的异常类型可能还不够)。
    • 同样,由于方法中的期望值很高,这取决于测试代码的编写方式,然后测试代码的错误部分会引发异常,从而导致测试结果为假阳性,并且我不确定PMDfindbugsSonar将提供有关此类代码的提示。

      @Test(expected = WantedException.class)
      public void call2_should_throw_a_WantedException__not_call1() {
          // init tested
          tested.call1(); // may throw a WantedException
      
          // call to be actually tested
          tested.call2(); // the call that is supposed to raise an exception
      }
  3. ExpectedException规则也是试图解决以前的警告,但由于使用期望样式,使用起来感觉有些尴尬,EasyMock用户非常了解这种样式。对于某些人来说可能很方便,但是如果您遵循行为驱动开发(BDD)或“ 安排行为声明”(AAA)原则,则该ExpectedException规则将不适合那些写作风格。除此之外,它可能会遇到与@Test方式相同的问题,具体取决于您放置期望的位置。

    @Rule ExpectedException thrown = ExpectedException.none()
    
    @Test
    public void call2_should_throw_a_WantedException__not_call1() {
        // expectations
        thrown.expect(WantedException.class);
        thrown.expectMessage("boom");
    
        // init tested
        tested.call1(); // may throw a WantedException
    
        // call to be actually tested
        tested.call2(); // the call that is supposed to raise an exception
    }

    即使将预期的异常放在测试语句之前,如果测试遵循BDD或AAA,它也会破坏您的阅读流程。

    另外,请参阅的作者关于JUnit的注释问题ExpectedExceptionJUnit 4.13-beta-2甚至不赞成使用此机制:

    拉取请求#1519:弃用ExpectedException

    Assert.assertThrows方法提供了一种更好的验证异常的方法。另外,与其他规则(例如TestWatcher)一起使用时,ExpectedException的使用容易出错,因为在这种情况下,规则的顺序很重要。

因此,以上所有这些选项都有很多警告,并且显然无法避免编码错误。

  1. 创建这个答案后,我意识到一个项目看起来很有希望,那就是catch-exception

    正如该项目的描述所言,它使编码人员可以流畅地编写一行代码来捕获该异常,并为后者的断言提供此异常。您可以使用任何声明库,例如HamcrestAssertJ

    从主页上摘录的一个快速示例:

    // given: an empty list
    List myList = new ArrayList();
    
    // when: we try to get the first element of the list
    when(myList).get(1);
    
    // then: we expect an IndexOutOfBoundsException
    then(caughtException())
            .isInstanceOf(IndexOutOfBoundsException.class)
            .hasMessage("Index: 1, Size: 0") 
            .hasNoCause();

    如您所见,代码确实非常简单,您可以在特定行上捕获异常,该thenAPI是将使用AssertJ API的别名(类似于using assertThat(ex).hasNoCause()...)。在某些时候,该项目依赖于FEST-声明AssertJ的祖先编辑:似乎该项目正在酝酿对Java 8 Lambdas的支持。

    当前,该库有两个缺点:

    • 在撰写本文时,值得注意的是,该库基于Mockito 1.x,因为它创建了幕后被测试对象的模拟。由于Mockito仍未更新,因此该库无法使用最终类或最终方法。即使它基于当前版本的Mockito 2,这也需要声明一个全局模拟制作器(inline-mock-maker),这可能不是您想要的,因为该模拟制作器与常规模拟制作器具有不同的缺点。

    • 它还需要另一个测试依赖项。

    一旦库支持lambda,这些问题将不再适用。但是,该功能将由AssertJ工具集复制。

    如果您不想使用catch-exception工具,请考虑所有因素,我将建议使用try- catch块的旧方法,至少是JDK7。对于JDK 8用户,您可能更喜欢使用AssertJ,因为它提供的不仅仅是断言异常。

  2. 使用JDK8,lambda进入了测试环境,事实证明它们是断言异常行为的一种有趣方式。AssertJ已更新,提供了一个很好的流利API来声明异常行为。

    以及使用AssertJ进行的示例测试:

    @Test
    public void test_exception_approach_1() {
        ...
        assertThatExceptionOfType(IOException.class)
                .isThrownBy(() -> someBadIOOperation())
                .withMessage("boom!"); 
    }
    
    @Test
    public void test_exception_approach_2() {
        ...
        assertThatThrownBy(() -> someBadIOOperation())
                .isInstanceOf(Exception.class)
                .hasMessageContaining("boom");
    }
    
    @Test
    public void test_exception_approach_3() {
        ...
        // when
        Throwable thrown = catchThrowable(() -> someBadIOOperation());
    
        // then
        assertThat(thrown).isInstanceOf(Exception.class)
                          .hasMessageContaining("boom");
    }
  3. 通过对JUnit 5的近乎完全的重写,断言得到了一些改进,作为断言适当断言的一种开箱即用的方式,它们可能被证明很有趣。但是实际上断言API仍然有点差,外面没有东西assertThrows

    @Test
    @DisplayName("throws EmptyStackException when peeked")
    void throwsExceptionWhenPeeked() {
        Throwable t = assertThrows(EmptyStackException.class, () -> stack.peek());
    
        Assertions.assertEquals("...", t.getMessage());
    }

    如您所见,assertEquals仍然在返回void,因此不允许像AssertJ这样的链式断言。

    另外,如果您还记得与Matcher或发生冲突的名称Assert,请准备与发生相同的冲突Assertions

我想得出结论,今天(2017年3月3日)AssertJ的易用性,可发现API,快速发展的步伐,作为一个事实上的测试依赖是JDK8最好的解决方案,无论测试框架(JUnit的还是不可以),即使以前的JDK 感到笨拙,也应该依靠try-catch块。

这个答案是从另一个问题获得的,该问题的知名度不一样,我是同一位作者。


1
添加org.junit.jupiter:junit-jupiter-engine:5.0.0-RC2依赖关系(除了已经存在的junit:junit:4.12之外)以能够使用assertThrows可能不是首选的解决方案,但是并没有引起任何后果。给我的问题。
ANRE

我很喜欢使用ExpectedException规则,但是它总是让我感到困扰,因为它会破坏AAA。您已经写了一篇很棒的文章来描述所有不同的方法,并且您绝对鼓励我尝试AssertJ :-)谢谢!
Pim Hazebroek '18

@PimHazebroek谢谢。AssertJ API非常丰富。在我看来,更好的是JUnit开箱即用的建议。
布莱斯

64

现在已经发布了JUnit 5和JUnit 4.13,最好的选择是使用Assertions.assertThrows() (对于JUnit 5)和Assert.assertThrows()(对于JUnit 4.13)。请参阅《Junit 5用户指南》

这是一个验证抛出异常并使用Truth对异常消息进行断言的示例:

public class FooTest {
  @Test
  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();

    IndexOutOfBoundsException e = assertThrows(
        IndexOutOfBoundsException.class, foo::doStuff);

    assertThat(e).hasMessageThat().contains("woops!");
  }
}

与其他答案中的方法相比,优点是:

  1. 内置于JUnit
  2. 如果lambda中的代码未引发异常,则会得到一条有用的异常消息,如果lambda中的代码未引发异常,则会得到一个堆栈跟踪信息
  3. 简洁
  4. 允许您的测试遵循“安排行为声明”
  5. 您可以精确指出要引发异常的代码
  6. 您无需在 throws子句中
  7. 您可以使用选择的断言框架对捕获的异常进行断言

org.junit Assert在JUnit 4.13 中将添加类似的方法。


这种方法是干净的,但是我看不出它如何允许我们的测试遵循“ Arrange-Act-Assert”,因为我们必须将“ Act”部分包装在“ assertThrow”中,这是一个断言。
发条

@Clockwork lambda是“行为”。Arrange-Act-Assert的目标是使代码简洁明了(从而易于理解和维护)。如您所说,这种方法是干净的。
NamshubWriter

我仍然希望我可以在“断言”部分中在测试结束时声明抛出和异常。在这种方法中,您需要将动作包装在第一个断言中以首先捕获它。
发条

这将需要在每个测试中使用更多代码来进行断言。那是更多的代码,并且容易出错。
NamshubWriter

42

怎么做:捕获一个非常普通的异常,确保它使它脱离catch块,然后断言该异常的类就是您期望的异常。如果a)异常的类型错误(例如,如果您改为使用Null指针),并且b)从未引发异常,则该断言将失败。

public void testFooThrowsIndexOutOfBoundsException() {
  Throwable e = null;

  try {
    foo.doStuff();
  } catch (Throwable ex) {
    e = ex;
  }

  assertTrue(e instanceof IndexOutOfBoundsException);
}

3
同样,当测试失败的一天到来时,您将看不到测试结果中的异常类型。
jontejj

通过更改最后的声明方式,可以对此进行一些改进。assertEquals(ExpectedException.class, e.getClass())测试失败时,将显示预期和实际值。
密码

37

BDD样式解决方案:JUnit 4 + 捕获异常 + AssertJ

import static com.googlecode.catchexception.apis.BDDCatchException.*;

@Test
public void testFooThrowsIndexOutOfBoundsException() {

    when(() -> foo.doStuff());

    then(caughtException()).isInstanceOf(IndexOutOfBoundsException.class);

}

依存关系

eu.codearte.catch-exception:catch-exception:2.0

36

使用AssertJ断言,可以与JUnit一起使用:

import static org.assertj.core.api.Assertions.*;

@Test
public void testFooThrowsIndexOutOfBoundsException() {
  Foo foo = new Foo();

  assertThatThrownBy(() -> foo.doStuff())
        .isInstanceOf(IndexOutOfBoundsException.class);
}

这样做要好,@Test(expected=IndexOutOfBoundsException.class)因为它可以保证测试中的预期行引发了异常,并使您可以更轻松地检查有关异常的更多详细信息,例如消息:

assertThatThrownBy(() ->
       {
         throw new Exception("boom!");
       })
    .isInstanceOf(Exception.class)
    .hasMessageContaining("boom");

Maven / Gradle说明在这里。


最简洁的方式,没人能理解,奇怪。我对assertJ库只有一个问题,assertThat与junit的名称冲突。有关assertJ throwby的更多信息:JUnit:使用Java 8和AssertJ 3.0.0测试异常〜Codeleak.pl
ycomp

@ycomp好吧,这是一个很老的问题的新答案,因此得分差异具有欺骗性。
weston

如果可以使用Java 8和AssertJ,那可能是最好的解决方案!
皮埃尔·亨利

@ycomp我怀疑此名称冲突可能是设计使然:AssertJ库因此强烈建议您不要使用JUnit assertThat,始终使用AssertJ。同样,JUnit方法仅返回“常规”类型,而AssertJ方法则返回一个AbstractAssert子类...允许如上所述对方法进行字符串化(或对此使用任何技术术语...)。
mike啮齿动物

实际上,@ weston我只是在AssertJ 2.0.0中使用了您的技术。毫无疑问,没有升级的借口,尽管您可能想知道。
mike啮齿动物

33

为了解决相同的问题,我确实设置了一个小项目:http : //code.google.com/p/catch-exception/

使用这个小帮手,你会写

verifyException(foo, IndexOutOfBoundsException.class).doStuff();

这不像JUnit 4.7的ExpectedException规则那么冗长。与skaffman提供的解决方案相比,您可以指定期望在哪一行代码中出现该异常。我希望这有帮助。


我也考虑过做类似的事情,但最终发现ExpectedException的真正功能是不仅可以指定预期的异常,还可以指定异常的某些属性,例如预期的原因或预期的消息。
杰森·汤普森

我的猜测是该解决方案具有与模拟相同的缺点吗?例如,如果foofinal它会失败,因为你不能代理foo
2014年

汤姆,如果doStuff()是接口的一部分,则代理方法将起作用。否则,这种方法将失败,您是对的。
rwitzel

31

更新: JUnit5对异常测试进行了改进:assertThrows

以下示例来自:Junit 5用户指南

 @Test
void exceptionTesting() {
    Throwable exception = assertThrows(IllegalArgumentException.class, () -> 
    {
        throw new IllegalArgumentException("a message");
    });
    assertEquals("a message", exception.getMessage());
}

使用JUnit 4的原始答案。

有几种方法可以测试是否引发了异常。我的文章中还讨论了以下选项:如何使用JUnit编写出色的单元测试

设置expected参数@Test(expected = FileNotFoundException.class)

@Test(expected = FileNotFoundException.class) 
public void testReadFile() { 
    myClass.readFile("test.txt");
}

使用 try catch

public void testReadFile() { 
    try {
        myClass.readFile("test.txt");
        fail("Expected a FileNotFoundException to be thrown");
    } catch (FileNotFoundException e) {
        assertThat(e.getMessage(), is("The file test.txt does not exist!"));
    }

}

使用ExpectedException规则进行测试。

@Rule
public ExpectedException thrown = ExpectedException.none();

@Test
public void testReadFile() throws FileNotFoundException {

    thrown.expect(FileNotFoundException.class);
    thrown.expectMessage(startsWith("The file test.txt"));
    myClass.readFile("test.txt");
}

您可以在JUnit4 Wiki中了解有关异常测试bad.robot-预期异常JUnit规则的更多信息


22

您也可以这样做:

@Test
public void testFooThrowsIndexOutOfBoundsException() {
    try {
        foo.doStuff();
        assert false;
    } catch (IndexOutOfBoundsException e) {
        assert true;
    }
}

12
在JUnit测试中,最好使用Assert.fail(),而不是assert,以防万一您的测试在未启用断言的环境中运行。
NamshubWriter

14

恕我直言,检查JUnit中异常的最佳方法是try / catch / fail / assert模式:

// this try block should be as small as possible,
// as you want to make sure you only catch exceptions from your code
try {
    sut.doThing();
    fail(); // fail if this does not throw any exception
} catch(MyException e) { // only catch the exception you expect,
                         // otherwise you may catch an exception for a dependency unexpectedly
    // a strong assertion on the message, 
    // in case the exception comes from anywhere an unexpected line of code,
    // especially important if your checking IllegalArgumentExceptions
    assertEquals("the message I get", e.getMessage()); 
}

assertTrue可能会有点强对某些人来说,这样assertThat(e.getMessage(), containsString("the message");可能是可取的。



13

我在Mkyong博客中找到了Junit 4的最灵活,最优雅的答案。它具有try/catch使用@Rule注释的灵活性。我喜欢这种方法,因为您可以读取自定义异常的特定属性。

package com.mkyong;

import com.mkyong.examples.CustomerService;
import com.mkyong.examples.exception.NameNotFoundException;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.Matchers.hasProperty;

public class Exception3Test {

    @Rule
    public ExpectedException thrown = ExpectedException.none();

    @Test
    public void testNameNotFoundException() throws NameNotFoundException {

        //test specific type of exception
        thrown.expect(NameNotFoundException.class);

        //test message
        thrown.expectMessage(is("Name is empty!"));

        //test detail
        thrown.expect(hasProperty("errCode"));  //make sure getters n setters are defined.
        thrown.expect(hasProperty("errCode", is(666)));

        CustomerService cust = new CustomerService();
        cust.findByName("");

    }

}

12

我在这里尝试了许多方法,但是它们要么很复杂,要么根本无法满足我的要求。实际上,可以很简单地编写一个辅助方法:

public class ExceptionAssertions {
    public static void assertException(BlastContainer blastContainer ) {
        boolean caughtException = false;
        try {
            blastContainer.test();
        } catch( Exception e ) {
            caughtException = true;
        }
        if( !caughtException ) {
            throw new AssertionFailedError("exception expected to be thrown, but was not");
        }
    }
    public static interface BlastContainer {
        public void test() throws Exception;
    }
}

像这样使用它:

assertException(new BlastContainer() {
    @Override
    public void test() throws Exception {
        doSomethingThatShouldExceptHere();
    }
});

零依赖性:无需模拟,无需powermock;并且在期末课程上也能正常工作。


有趣,但不适合AAA(安排法案断言),您要在实际上不同的步骤中执行法案和断言步骤。
bln-tom 2014年

1
@ bln-tom从技术上讲这是两个不同的步骤,只是顺序不一样。; p
Trejkaz 2015年

10

Java 8解决方案

如果您需要以下解决方案:

  • 利用Java 8 Lambda
  • 难道依赖于任何JUnit的魔法
  • 允许您在一个测试方法中检查多个异常
  • 检查您的测试方法中的特定行集而不是整个测试方法中的任何未知行引发的异常
  • 产生实际抛出的异常对象,以便您可以进一步检查它

这是我写的一个实用函数:

public final <T extends Throwable> T expectException( Class<T> exceptionClass, Runnable runnable )
{
    try
    {
        runnable.run();
    }
    catch( Throwable throwable )
    {
        if( throwable instanceof AssertionError && throwable.getCause() != null )
            throwable = throwable.getCause(); //allows "assert x != null : new IllegalArgumentException();"
        assert exceptionClass.isInstance( throwable ) : throwable; //exception of the wrong kind was thrown.
        assert throwable.getClass() == exceptionClass : throwable; //exception thrown was a subclass, but not the exact class, expected.
        @SuppressWarnings( "unchecked" )
        T result = (T)throwable;
        return result;
    }
    assert false; //expected exception was not thrown.
    return null; //to keep the compiler happy.
}

摘自我的博客

如下使用它:

@Test
public void testThrows()
{
    RuntimeException e = expectException( RuntimeException.class, () -> 
        {
            throw new RuntimeException( "fail!" );
        } );
    assert e.getMessage().equals( "fail!" );
}


8

就我而言,我总是从db获取RuntimeException,但是消息有所不同。并且异常需要分别处理。这是我测试的方式:

@Test
public void testThrowsExceptionWhenWrongSku() {

    // Given
    String articleSimpleSku = "999-999";
    int amountOfTransactions = 1;
    Exception exception = null;

    // When
    try {
        createNInboundTransactionsForSku(amountOfTransactions, articleSimpleSku);
    } catch (RuntimeException e) {
        exception = e;
    }

    // Then
    shouldValidateThrowsExceptionWithMessage(exception, MESSAGE_NON_EXISTENT_SKU);
}

private void shouldValidateThrowsExceptionWithMessage(final Exception e, final String message) {
    assertNotNull(e);
    assertTrue(e.getMessage().contains(message));
}

1
在带有的行之前} catch (,您应插入fail("no exception thrown");
Daniel Alder

6

只需制作一个可以关闭和打开的Matcher,如下所示:

public class ExceptionMatcher extends BaseMatcher<Throwable> {
    private boolean active = true;
    private Class<? extends Throwable> throwable;

    public ExceptionMatcher(Class<? extends Throwable> throwable) {
        this.throwable = throwable;
    }

    public void on() {
        this.active = true;
    }

    public void off() {
        this.active = false;
    }

    @Override
    public boolean matches(Object object) {
        return active && throwable.isAssignableFrom(object.getClass());
    }

    @Override
    public void describeTo(Description description) {
        description.appendText("not the covered exception type");
    }
}

要使用它:

添加public ExpectedException exception = ExpectedException.none();,然后:

ExceptionMatcher exMatch = new ExceptionMatcher(MyException.class);
exception.expect(exMatch);
someObject.somethingThatThrowsMyException();
exMatch.off();

6

在JUnit 4或更高版本中,您可以如下测试异常

@Rule
public ExpectedException exceptions = ExpectedException.none();


这提供了许多可用于改进我们的JUnit测试的功能。
如果您看到以下示例,则我正在测试有关异常的3件事。

  1. 引发的异常类型
  2. 异常消息
  3. 异常原因


public class MyTest {

    @Rule
    public ExpectedException exceptions = ExpectedException.none();

    ClassUnderTest classUnderTest;

    @Before
    public void setUp() throws Exception {
        classUnderTest = new ClassUnderTest();
    }

    @Test
    public void testAppleisSweetAndRed() throws Exception {

        exceptions.expect(Exception.class);
        exceptions.expectMessage("this is the exception message");
        exceptions.expectCause(Matchers.<Throwable>equalTo(exceptionCause));

        classUnderTest.methodUnderTest("param1", "param2");
    }

}

6

我们可以在必须返回异常的方法之后使用断言失败:

try{
   methodThatThrowMyException();
   Assert.fail("MyException is not thrown !");
} catch (final Exception exception) {
   // Verify if the thrown exception is instance of MyException, otherwise throws an assert failure
   assertTrue(exception instanceof MyException, "An exception other than MyException is thrown !");
   // In case of verifying the error message
   MyException myException = (MyException) exception;
   assertEquals("EXPECTED ERROR MESSAGE", myException.getMessage());
}

3
catch如果抛出其他异常,第二个将吞没堆栈跟踪,从而丢失有用的信息
NamshubWriter 2015年

5

除了NamShubWriter所说的以外,请确保:

  • ExpectedException实例是public相关问题
  • 该的ExpectedException 不是在说实例化,@Before方法。这篇文章清楚地解释了JUnit执行顺序的所有复杂性。

难道不是这样做:

@Rule    
public ExpectedException expectedException;

@Before
public void setup()
{
    expectedException = ExpectedException.none();
}

最后,博客文章清楚地说明了如何断言某个异常被抛出。


4

我建议库assertj-core在junit测试中处理异常

在Java 8中,如下所示:

//given

//when
Throwable throwable = catchThrowable(() -> anyService.anyMethod(object));

//then
AnyException anyException = (AnyException) throwable;
assertThat(anyException.getMessage()).isEqualTo("........");
assertThat(exception.getCode()).isEqualTo(".......);

2

Java8的Junit4解决方案是使用此功能:

public Throwable assertThrows(Class<? extends Throwable> expectedException, java.util.concurrent.Callable<?> funky) {
    try {
        funky.call();
    } catch (Throwable e) {
        if (expectedException.isInstance(e)) {
            return e;
        }
        throw new AssertionError(
                String.format("Expected [%s] to be thrown, but was [%s]", expectedException, e));
    }
    throw new AssertionError(
            String.format("Expected [%s] to be thrown, but nothing was thrown.", expectedException));
}

用法是:

    assertThrows(ValidationException.class,
            () -> finalObject.checkSomething(null));

请注意,唯一的限制是final在lambda表达式中使用对象引用。该解决方案允许继续测试断言,而不是期望使用@Test(expected = IndexOutOfBoundsException.class)解决方案在方法级别可允许使用。


1

例如,您要为下面提到的代码片段编写Junit

public int divideByZeroDemo(int a,int b){

    return a/b;
}

public void exceptionWithMessage(String [] arr){

    throw new ArrayIndexOutOfBoundsException("Array is out of bound");
}

上面的代码用于测试可能发生的某些未知异常,而下面的代码用于使用自定义消息声明某些异常。

 @Rule
public ExpectedException exception=ExpectedException.none();

private Demo demo;
@Before
public void setup(){

    demo=new Demo();
}
@Test(expected=ArithmeticException.class)
public void testIfItThrowsAnyException() {

    demo.divideByZeroDemo(5, 0);

}

@Test
public void testExceptionWithMessage(){


    exception.expectMessage("Array is out of bound");
    exception.expect(ArrayIndexOutOfBoundsException.class);
    demo.exceptionWithMessage(new String[]{"This","is","a","demo"});
}

1
    @Test(expectedException=IndexOutOfBoundsException.class) 
    public void  testFooThrowsIndexOutOfBoundsException() throws Exception {
         doThrow(IndexOutOfBoundsException.class).when(foo).doStuff();  
         try {
             foo.doStuff(); 
            } catch (IndexOutOfBoundsException e) {
                       assertEquals(IndexOutOfBoundsException .class, ex.getCause().getClass());
                      throw e;

               }

    }

这是检查方法是否抛出正确异常的另一种方法。


1

JUnit框架具有以下assertThrows()方法:

ArithmeticException exception = assertThrows(ArithmeticException.class, () ->
    calculator.divide(1, 0));
assertEquals("/ by zero", exception.getMessage());

0

使用Java 8,您可以创建一个以代码检查和预期异常为参数的方法:

private void expectException(Runnable r, Class<?> clazz) { 
    try {
      r.run();
      fail("Expected: " + clazz.getSimpleName() + " but not thrown");
    } catch (Exception e) {
      if (!clazz.isInstance(e)) fail("Expected: " + clazz.getSimpleName() + " but " + e.getClass().getSimpleName() + " found", e);
    }
  }

然后在测试中:

expectException(() -> list.sublist(0, 2).get(2), IndexOutOfBoundsException.class);

优点:

  • 不依赖任何图书馆
  • 本地化检查-更精确,并且如果需要,可以在一个测试中包含多个这样的断言
  • 易于使用
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.