EasyMock期待私有方法调用

KWJ*_*104 3 java unit-testing easymock

让我们说我有一个看起来像这样的方法:

public static String[] parseFoo(Foo anObject){
    Foo anotherObject = parseFoo2(anObject);
...
}

private static Foo parseFoo2(Foo anObject){
...
}
Run Code Online (Sandbox Code Playgroud)

并且两种方法都属于同一类.parseFoo2只是一个辅助方法,可以帮助parseFoo完成一些事情.我正在尝试测试方法parseFoo.在EasyMock中是否有人可以在parseFoo2的私有方法调用上指定返回值,就像我可以为对象指定实例方法调用一样

EasyMock.createMock(...);
anObject.expect(...).andReturn(...);
Run Code Online (Sandbox Code Playgroud)

因为我想测试公共方法,但我不想进入私有方法并测试里面的实现.

谢谢

Vit*_*liy 13

不要这样做.良好的单元测试的一个基石是它应该尽可能少地依赖于实现细节.嘲笑私有方法就是这样.

为什么?因为这会使你的单元测试变得非常脆弱.考虑一下你在一周内回到这段代码并确定你真的不需要方法parseFoo2并且你真的想要内联其代码的情况.或者您想将此方法拆分为两个或更多较小的方法.所有非常有效的重构实践 - 但它们将打破单元测试!

每次进行这样的简单重构时,您都不希望追逐单元测试.因此,模拟私有方法被认为是不好的做法.

  • 这个答案太过绝对主义,而且私人方法没有一个应该被引用的内部契约需要一个哲学的观点.如果该方法在类中的几个地方使用,它就像一个公共方法,因为它需要维护它的行为模式.此外,如果你有一个方法调用几个方法(所有私有),每个方法有2-3个逻辑路径测试顶级方法变得非常复杂.当你需要登记时,没有什么比失败的复杂测试更糟糕了:).我更喜欢偶尔出现障碍的频繁预测成本. (2认同)
  • @Gus,我不同意.从实用的角度来看,以高粒度测试私有方法会阻止您轻松地重构代码.我同意,随着复杂性的增加,应该将应该单独测试的部分考虑在内.在这种情况下应考虑类.从哲学的角度来看,我认为一个类的私有部分不是一个应该被测试的单元.它是一个实现细节,而测试应该反映测试对象的要求,而不是其内部工作. (2认同)

Mak*_*oto 8

如果您发现必须模拟私有方法,那么您可以使用PowerMock.expectPrivate().EasyMock无法模拟私有方法.