java – 使用Mockito调用多个其他方法的方法的单元测试

发布时间：2020-12-15 00:51:55 所属栏目：Java 来源：网络整理

导读：也许我在搜索中完全没有做到,但我找不到任何与如何为 Java类/方法编写单元测试相关的文档或讨论,而Java类/方法又调用其他非私有方法.看起来,如果必须使用间谍来测试一个需要模拟内部方法调用的方法,Mockito就会认为设计可能有问题(不是真正的OO).我不确定这

也许我在搜索中完全没有做到,但我找不到任何与如何为 Java类/方法编写单元测试相关的文档或讨论,而Java类/方法又调用其他非私有方法.看起来,如果必须使用间谍来测试一个需要模拟内部方法调用的方法,Mockito就会认为设计可能有问题(不是真正的OO).我不确定这是永远的.但是使用间谍似乎是实现这一目标的唯一方法.例如,为什么你不能有一个“包装”样式方法,而这种方法依赖于原始功能的其他方法,但另外提供功能,错误处理,日志记录或依赖于其他方法的结果的不同分支等？

所以我的问题是双重的：

>设计不良和实现的代码是否有内部调用其他方法的方法？
>如果选择Mockito作为他们的模拟框架,那么为这种方法编写单元测试的最佳实践和/或方法是什么(假设它本身是一个好主意)？

这可能是一个困难的要求,但我更愿意那些决定回答不仅重新发布Mockito措辞和/或对间谍的立场的人,因为我已经意识到这种方法和意识形态.另外,我也使用过Powermockito.对我来说,问题在于Mockito开发了这个框架,其中必须创建额外的解决方案来支持这种需求.所以我想我想要回答的问题是,如果间谍是“坏”,并且Powermockito不可用,那么如何对一个调用其他非私有方法的方法进行单元测试呢？

解决方法

Is it poorly designed and implemented code to have a method that internally calls other methods?

并不是的.但是我要说的是,在这种情况下,应该测试调用其他方法的方法,就像其他未经过单独测试的方法一样.
也就是说,它可以保护您免受公共方法在没有注意到的情况下停止调用其他方法的情况.

是的,它(有时)会产生大量的测试代码.我相信这就是重点：编写测试的痛苦是一个很好的线索,你可能想要考虑将这些子方法提取到一个单独的类中.

如果我可以忍受那些测试,那么我认为子方法还没有被提取出来.

What is the best practice and/or approach in writing a unit test for such a method (assuming it is itself a good idea) if one has chosen Mockito as their mocking framework?

我会做那样的事情：

public class Blah {
    public int publicMethod() {
        return innerMethod();
    }

    int innerMethod() {
        return 0;
    }
}


public class BlahTest {
    @Test
    public void blah() throws Exception {
        Blah spy = spy(new Blah());
        doReturn(1).when(spy).innerMethod();

        assertThat(spy.publicMethod()).isEqualTo(1);
    }
}

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!