关于测试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.

Private Methods

Private Methods Methods can also be private within a class and inaccessible outside of the class. ...
  • likaiwalkman
  • likaiwalkman
  • 2014-01-08 19:14:10
  • 437

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

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

abstract的methods不能以private修饰(Java)

有如下错误代码:abstract class Something { private abstract String doSomething (); } 解析: abstract的methods...
  • hengbao4
  • hengbao4
  • 2016-09-11 19:21:47
  • 949

11年JAVA大牛使用示例带你提前了解 Java 9 中的新特性

ava 作为 Android 的基础编程语言,每一次迭代也是备受安卓开发人员的关注。这不,Oracle 公司在今年即将发布 Java 9 正式版,一些新的特性和改进很是值得期待。 周末时间,拜读...
  • a318804626
  • a318804626
  • 2017-12-22 14:22:38
  • 92

junit 测试报错 java.lang.Exception: No runnable methods

转自:http://blog.csdn.net/snails_zx/article/details/51275894 在maven 项目中  建立测试类时,基类只用作加载spring配置...
  • zx1323
  • zx1323
  • 2017-08-27 14:18:02
  • 3025

Junit测试private方法

Java代码   package com.bill99.junit;      public class ACase {          private String echo...
  • iameyama
  • iameyama
  • 2015-12-27 02:40:07
  • 2079

[JAVA]在Junit中测试私有函数的方法(junit, private, method)

eclipse中如何写一个测试私有方法的junit?假设类Summer定义如下:public class Summer{   private int methodone(String argsone)...
  • szwangdf
  • szwangdf
  • 2005-11-20 18:33:00
  • 4103

[java]junit测试private方法

测试private methodsJunit FAQHow do I test private methods?Testing private methods may be an indication...
  • believefym
  • believefym
  • 2008-04-17 18:58:00
  • 7580

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

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

Spring Boot单元测试编译报错 No runnable methods

1.第一种情况,有的测试类为空,只定义了一个类名,也就是类里面没有能运行的方法 2.第二种情况,测试类方法有错,或者没有添加注解。...
  • u010429286
  • u010429286
  • 2016-12-08 16:56:44
  • 1574
收藏助手
不良信息举报
您举报文章:关于测试private methods
举报原因:
原因补充:

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