所以我的问题是双重的:
>设计不良和实现的代码是否有内部调用其他方法的方法?
>如果选择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); } }
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。