首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

我不能理解junit mockito测试中willThrow、doThrow的逻辑

在JUnit Mockito测试中,willThrow和doThrow是Mockito框架中的两个方法,用于模拟方法调用时的异常情况。

  1. willThrow方法: willThrow方法用于模拟当调用某个方法时抛出指定的异常。它的语法如下:
代码语言:txt
复制
when(mockObject.someMethod()).willThrow(ExceptionClass.class);

这里的mockObject是我们创建的模拟对象,someMethod是该模拟对象上的一个方法。当我们调用someMethod方法时,会抛出指定的异常。可以通过指定不同的异常类来模拟不同的异常情况。

示例代码:

代码语言:txt
复制
@Test(expected = SomeException.class)
public void testSomeMethod() throws SomeException {
    MockObject mockObject = mock(MockObject.class);
    when(mockObject.someMethod()).willThrow(SomeException.class);
    // ...
    // 执行测试代码,调用someMethod方法
    // ...
}

在上述代码中,当执行mockObject.someMethod()时,会抛出SomeException异常。

  1. doThrow方法: doThrow方法也用于模拟方法调用时抛出异常的情况,与willThrow方法的语法略有不同。doThrow方法的使用如下:
代码语言:txt
复制
doThrow(ExceptionClass.class).when(mockObject).someMethod();

在这个语法中,我们通过doThrow方法指定当调用mockObject对象的someMethod方法时抛出指定的异常。

示例代码:

代码语言:txt
复制
@Test(expected = SomeException.class)
public void testSomeMethod() throws SomeException {
    MockObject mockObject = mock(MockObject.class);
    doThrow(SomeException.class).when(mockObject).someMethod();
    // ...
    // 执行测试代码,调用someMethod方法
    // ...
}

在上述代码中,当执行mockObject.someMethod()时,会抛出SomeException异常。

这两个方法在单元测试中通常用于模拟异常情况,以测试异常处理的逻辑是否正确。通过模拟方法抛出异常,我们可以确保被测试的代码能够正确地处理这些异常情况,提高代码的健壮性。

对于这个问题的答案,如果您想了解更多关于JUnit和Mockito的内容,可以查看腾讯云的测试产品文档:腾讯云云测产品介绍

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

单元测试以及JUnit框架解析

我们都有个习惯,常常不乐意去写个简单的单元测试程序来验证自己的代码。对自己的程序一直非常有自信,或存在侥幸心理每次运行通过后就直接扔给测试组测试了。然而每次测试组的BUG提交过来后就会发现自己的程序还存在许多没有想到的漏洞。但是每次修改好BUG以后还是怀着侥幸心理,认为这次不会有bug了。然后又一次自信地提交,结果又败了。因为这样反复几次后。开发者花在找BUG和修复BUG的这些时间加起来已经比他开发这个模块花的时间还要多了。虽然项目经理已经预留了修改BUG和单元测试的时间。但是开发者却习惯性地在写好代码后就认为任务完成了。 然后等问题出来了bug改了很多次还是修复不了的时候才和项目经理说“我碰到预想不到的问题,可能要延期发布我的代码“。如果这个项目不可延期,痛苦的加班就无法避免了。

02

玩花招的PowerMock

当我们面对一个遗留系统时,常见的问题是没有测试。正如Michael Feathers在Working Effectively with Legacy Code一书中对“遗留代码”的定义。他将其简单归纳为“没有测试的代码”。真是太贴切了!正是因为没有测试,使得我们对遗留代码的任何重构都有些战战兢兢,甚至成为开发人员抵制重构的借口。从收益与成本的比例来看,对于这样的系统,我一贯认为不要盲目进行重构。因为重构的真正适用场景其实是发生在开发期间,而非维护期间。当然,提升自己的重构能力,尤其学会运用IDE提供的自动重构工具,可以在一定程度上保障重构的质量。然而,安全的做法,还是需要为其编写测试。

02

[Android技术专题]每个开发者都应该懂一点单元测试

笔者在项目中实际有写过单元测试的代码,也用过一些单元测试的框架,但对单元测试的理解都很浅显,直到有一次在InfoQ编辑徐川主导的微信群里面看了蘑菇街小创同学的分享,加深了我对单元测试的兴趣和理解,他针对android平台的单元测试写了一个系列的文章,从什么是单元测试、单元测试的意义、各种方法怎样做单元测试、单元测试和集成测试的区别、各种测试框架和开源库在写单元测试时如何很好地被使用、以及如何mock、在PC上运行需要依赖android设备环境的测试等方面都做了非常详细的介绍,下文中的很多观念都是看了他的文章吸收得来的。

03
领券