关于测试private methods

原创 2004年08月19日 11:19:00

看看Java中是如何进行private methods的测试的

Testing Private Methods with JUnit and SuiteRunner

So whether you are using JUnit or SuiteRunner, you have the same four basic approaches to testing private methods:

  • Don't test private methods.
  • Give the methods package access.
  • Use a nested test class.
  • Use reflection.

当然更多的建议不要对private methods测试

Approach 1: Don't Test Private Methods

As I mentioned in the introduction, I first heard the advice to suppress my occasional urges to test private methods from Daniel Steinberg. But Daniel is not only source of this advice that I have encountered. It seems to be a common attitude in the Java community. For example, the JUnit FAQ [4] states:

Testing private methods may be an indication that those methods should be moved into another class to promote reusability.

Charles Miller expressed a similar point of view in his weblog [5]:

If you have a thorough suite of tests for a class's exposed (non-private) interface, those tests should, by their nature, verify that any private method within the class also works. If this isn't the case, or if you have a private method so complex that it needs to be tested out of the context of its public callers, I would consider that a code-smell.

And Dave Thomas and Andy Hunt, in their book Pragmatic Unit Testing [6], write:

In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out.

I believe all this advice. Most of the time, private methods can be most effectively tested via approach 1, indirectly by testing the package-level, protected, and public methods that call them. But inevitably, some people in some situations will feel that directly testing a private method is the right thing to do.

In my case, I tend to create many private utility methods. These utility methods often do nothing with instance data, they just operate on the passed parameters and return a result. I create such methods to make the calling method easier to understand. It is a way to manage the complexity of the implementation of the class. Now, if I extract the private method out of a method that already works and has good unit test coverage, then those existing unit tests will likely suffice. I needn't write more unit tests just for the private method. But if I want to write the private method before its calling method, and I want to write the unit tests before writing the private method, I'm back to wanting to directly test the private method. In the case of private utility methods, I don't feel my urge to directly test the methods is, as the JUnit FAQ put it, "an indication that those methods should be moved into another class to promote reusability." These methods are really only needed in the class in which they reside, and in fact are often only called by one other method.

Another reason I sometimes feel the urge to test private methods directly is that I tend to think of unit testing as helping me achieve a robust system by building that system out of robust parts. Each part is a "unit" for which I can write "unit tests." The unit tests help me ensure each unit is functioning correctly, which in turn helps me build a system that functions correctly as a whole. The primary unit I think in terms of when programming in Java is the class. I build systems out of classes, and unit tests give me confidence that my classes are robust. But to some extent I also feel the same way about the private methods out of which I compose package-access, protected, and public methods. These private methods are units that can be tested individually. Such unit tests give me confidence that the private methods are working correctly, which helps me build package-access, protected, and public methods that are robust.

深入理解 ButterKnife,让你的程序学会写代码

0、引子 话说我们做程序员的,都应该多少是个懒人,我们总是想办法驱使我们的电脑帮我们干活,所以我们学会了各式各样的语言来告诉电脑该做什么——尽管,他们有时候也会误会我们的意思。 突然有一天,我觉得...
  • f2006116
  • f2006116
  • 2016年07月15日 21:57
  • 1173

使用PowerMock和Easymock进行单元测试

Java单元测试对于开发人员质量保证至关重要,尤其当面对一团乱码的遗留代码时,没有高覆盖率的单元测试做保障,没人敢轻易对代码进行重构。然而单元测试的编写也不是一件容易的事情,除非使用TDD方式,否则编...
  • u010860412
  • u010860412
  • 2016年02月16日 20:11
  • 1252

Junit4 单元测试 private 私有方法 abstract类

一句话说明单元测试的意义: 显著提高从上到下结构项目的可维护性和健壮性, 保证多个类之间的依赖关系正确. private方法的单元测试, abstract类的单元测试是两个难点, 本文给出了解决方案....
  • caib1109
  • caib1109
  • 2016年05月07日 18:25
  • 3298

Mocking private methods

Quick summary Use the @RunWith(PowerMockRunner.class) annotation at the class-level of the test c...
  • joyyq
  • joyyq
  • 2012年07月21日 21:48
  • 317

private与static的方法是不是默认为final的测试

读了thinkinjava后,说private与static的方法是final的,只是把final关键字给隐藏了。自己测试了下, public class Father { private...
  • wanghuicai_123
  • wanghuicai_123
  • 2012年05月15日 11:41
  • 954

java测试private方法

引用:http://blog.csdn.net/badwps/article/details/1629990 当Java的类有一个方法的访问修饰符是private,我们在写测试类时该怎样对它进行测试...
  • wtfpewfn
  • wtfpewfn
  • 2012年05月04日 10:31
  • 479

C++学习笔记之:关于类的一些补充测试(new和new[]/private构造/explicit等)

使用new/delete/new[]/delete[]的原则一般是成对使用,但是如果不成对会有什么结果呢 测试1 #include #include using namespace std; cl...
  • moest
  • moest
  • 2015年05月11日 19:09
  • 166

如何创建以太坊本地私有测试链Setting up a local private testnet

Setting up a local private testnet eth (C++ client) It is possible to connect to or create a new...
  • fidelhl
  • fidelhl
  • 2016年09月17日 07:38
  • 1366

测试 Java 类的private和protected变量和方法

转载说明:我转的这哥们也是转别人的,但是我没找到转载li
  • woshiniudun
  • woshiniudun
  • 2014年08月13日 10:57
  • 1683

C++单元测试三:测试private成员

测与不测之争 关于类的私有成员(数据和方法),要不要进行单元测试之争,尚没有统一的结论;(关于这一争论,可以参考http://stackoverflow.com/questions/9202862/...
  • henan_lujun
  • henan_lujun
  • 2013年06月03日 14:48
  • 2863
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于测试private methods
举报原因:
原因补充:

(最多只允许输入30个字)