对于仅用于测试的方法。。为什么不把它们作为实际测试代码的一部分呢？至少在Maven这样的构建系统中，测试代码不包含在打包的jar中，并且只作为源代码的一部分分发。从这个意义上说，它不能从普通类中调用，因为它根本不包含在最终的.jar（或.war）中。
我经常编写这样的方法来使我的测试代码更易于维护。
澄清：

src/
  main/
    java/
      my/package/
        MyClass.java <-- leave necessary protected accessors here
  test/
    java/
      my/package/
        MyClassTest.java <-- implement test-code here

字符串
在MyClassTest中...

public class MyClassTest {

   ...

   private static Foo doSomethingCoolButTesty(MyClass instance) {
       // access protected or package-private MyClass code here 
   }
}

型
MyClassTest.doSomethingCoolButTesty将与主代码分开，并且显然仅可用于测试代码。是的，这比将其作为主代码的方法更丑陋，但我发现这是一个公平的代价。

你需要这种方法的目的是什么？
（J）UnitTests应该通过使用类的 public interface 来验证类的 behavior。在单元测试中不应使用被测试代码中的“特殊”方法。

但是Unittests应该用 test doubles（也就是fakes和mock）替换测试代码的 dependencies。提供这些测试替身的首选方法是 * 依赖注入 *（DI）。

有时候，将DI引入到代码中需要付出很多努力。在这种情况下，引入 * 低可见性getter方法 * 作为接缝是可以接受的，其中依赖性可以被mock替换。

class CodeUnderTest{
  private final SomeOtherClass dependency = new SomeOtherClass();
  SomeOtherClass getDependency(){ // package private getter
    return dependency;
  }
  public void doSomething(){
     dependency.expectedMethodCalled();
  }
}

个字符

没有什么可以阻止在junit测试用例的“外部”调用方法。
我务实的回答是：使方法包受保护，并添加一个简单的注解，如“仅限单元测试”作为javadoc。并教育你的团队荣誉这样的声明。
理想情况下：以一种不需要这些“技巧”的方式来设计你的产品代码，以使它可测试！
鉴于对该问题的评论：技术上可能以某种方式获取堆栈跟踪信息;然后在相应的方法上搜索@Test注解的存在。但这似乎是绝对的矫枉过正--这意味着要在生产代码中添加更多的“仅测试”代码。
而且这也将是错误的方法-因为它试图用技术手段解决一个“社会”问题：如果你不想让人们调用某个方法，那么确保他们理解。

复制自How do I test a class that has private methods, fields or inner classes?
您可以使用反射来避开字段和方法的可见性。其他人正确地指出，私有函数不应该被测试，但我个人有这样的用例，即在正常情况下，除了构造函数之外，不应该有一个setter或任何写访问。