private 함수나 private 메서드, 필드 또는 내부 클래스가 있는 클래스를 테스트하려면 어떻게 해야 합니까?

질문자 :Community Wiki

내부 전용 메서드, 필드 또는 중첩 클래스가 있는 클래스를 단위 테스트(xUnit 사용)하려면 어떻게 해야 합니까?또는 내부 연결 ( static )을 사용하여 비공개로 만들거나 비공개( 익명 ) 네임스페이스에 있는 함수는 무엇입니까?

테스트를 실행할 수 있도록 메서드나 함수에 대한 액세스 한정자를 변경하는 것은 좋지 않은 것 같습니다.

업데이트:

약 10년 후 아마도 개인 메서드 또는 액세스할 수 없는 멤버를 테스트하는 가장 좋은 방법 은 Manifold 프레임워크 @Jailbreak 를 사용하는 것입니다.

 @Jailbreak Foo foo = new Foo(); // Direct, *type-safe* access to *all* foo's members foo.privateMethod(x, y, z); foo.privateField = value;

이렇게 하면 코드가 유형 안전하고 읽기 쉬운 상태로 유지됩니다. 디자인 타협이 없고 테스트를 위해 방법과 필드를 과도하게 노출하지 않습니다.

레거시 Java 응용 프로그램이 어느 정도 있고 메서드의 가시성을 변경할 수 없는 경우 개인 메서드를 테스트하는 가장 좋은 방법은 리플렉션 을 사용하는 것입니다.

private 및 private static private 및 private static 메서드를 호출하기 위해 도우미를 사용하고 있습니다. 다음 패턴을 사용하면 private 메서드 및 필드와 관련된 거의 모든 작업을 수행할 수 있습니다. 물론 리플렉션을 통해 private static final 변수를 변경할 수는 없습니다.

 Method method = TargetClass.getDeclaredMethod(methodName, argClasses); method.setAccessible(true); return method.invoke(targetObject, argObjects);

필드의 경우:

 Field field = TargetClass.getDeclaredField(fieldName); field.setAccessible(true); field.set(object, value);

---

노트:
1. TargetClass.getDeclaredMethod(methodName, argClasses) private 메서드를 살펴볼 수 있습니다. getDeclaredField 에도 동일한 사항이 적용됩니다.
2. setAccessible(true) 은 private을 가지고 노는 데 필요합니다.

Community Wiki

비공개 방법을 테스트하는 가장 좋은 방법은 다른 공개 방법을 사용하는 것입니다. 이 작업을 수행할 수 없는 경우 다음 조건 중 하나가 참입니다.

1. 개인 방법은 데드 코드입니다.
2. 테스트하는 클래스 근처에 디자인 냄새가 있습니다.
3. 테스트하려는 방법은 비공개가 아니어야 합니다.

Community Wiki

내가 private 메소드를 직접 테스트할 필요를 느낄 정도로 충분히 복잡한 클래스에 private 메소드가 있는 경우, 그것은 코드 냄새입니다. 내 클래스가 너무 복잡합니다.

이러한 문제를 해결하기 위한 나의 일반적인 접근 방식은 흥미로운 부분이 포함된 새 클래스를 찾아내는 것입니다. 종종 이 메서드와 상호 작용하는 필드, 그리고 다른 메서드 한두 개를 새 클래스로 추출할 수 있습니다.

새 클래스는 이러한 메서드를 '공개'로 노출하므로 단위 테스트에 액세스할 수 있습니다. 새 클래스와 기존 클래스는 이제 원래 클래스보다 더 간단해 저에게 좋습니다.

사람들이 두뇌를 사용하지 않고 수업을 만들라고 제안하는 것이 아닙니다! 여기서 요점은 단위 테스트의 힘을 사용하여 좋은 새 클래스를 찾는 데 도움이 된다는 것입니다.

Community Wiki

나는 과거에 자바를 위해 이것을 하기 위해 리플렉션 을 사용했고, 내 생각에 그것은 큰 실수였다.

엄밀히 말하면 private 메소드를 직접 테스트하는 단위 테스트를 작성 해서는 안됩니다. 테스트해야 하는 것은 클래스가 다른 객체와 맺는 공개 계약입니다. 개체의 내부를 직접 테스트해서는 안 됩니다. 다른 개발자가 클래스 공개 계약에 영향을 미치지 않는 작은 내부 변경을 클래스에 적용하려는 경우 해당 개발자는 리플렉션 기반 테스트를 수정하여 작동하는지 확인해야 합니다. 프로젝트 전체에서 이것을 반복적으로 수행하면 단위 테스트가 코드 상태에 대한 유용한 측정이 되지 않고 개발에 방해가 되기 시작하고 개발 팀에 짜증이 나기 시작합니다.

대신에 내가 추천하는 것은 Cobertura와 같은 코드 검사 도구를 사용하여 작성한 단위 테스트가 개인 메서드에서 코드의 적절한 검사를 제공하도록 하는 것입니다. 그렇게 하면 프라이빗 메서드가 수행하는 작업을 간접적으로 테스트하고 더 높은 수준의 민첩성을 유지할 수 있습니다.

Community Wiki

이 기사: JUnit 및 SuiteRunner(Bill Venners)를 사용하여 비공개 메소드 테스트 에는 기본적으로 4가지 옵션이 있습니다.

1. 개인 메서드를 테스트하지 마십시오.
2. 메소드 패키지 액세스 권한을 부여하십시오.
3. 중첩 테스트 클래스를 사용합니다.
4. 반사를 사용합니다.

Community Wiki

일반적으로 단위 테스트는 클래스 또는 단위의 공용 인터페이스를 실행하기 위한 것입니다. 따라서 개인 메서드는 명시적으로 테스트할 것으로 예상되지 않는 구현 세부 사항입니다.

Community Wiki

개인 메서드를 테스트하려는 두 가지 예:

1. 복호화 루틴 - 나는 단지 테스트를 위해서만 볼 수 있도록 다른 사람이 볼 수 있도록 하고 싶지 않습니다. 그렇지 않으면 누구나 복호화에 사용할 수 있습니다. SecurityManager 가 이를 방지하도록 구성되지 않은 경우 대부분의 경우 비공개 메서드를 보는 데 사용할 수 있는 반사는 명백한 예외입니다).
2. 커뮤니티 사용을 위한 SDK 만들기. 여기에서 public은 완전히 다른 의미를 갖습니다. 이것은 전 세계가 볼 수 있는 코드이기 때문입니다(내 응용 프로그램 내부에서만이 아님). SDK 사용자가 코드를 보지 못하도록 하려면 개인 메서드에 코드를 넣습니다. 저는 이것을 코드 냄새로 보지 않고 단지 SDK 프로그래밍이 작동하는 방식으로 봅니다. 하지만 물론 여전히 내 개인 메서드를 테스트해야 하며 내 SDK의 기능이 실제로 존재하는 곳입니다.

"계약"만 테스트한다는 아이디어를 이해합니다. 그러나 실제로 코드를 테스트하지 않는 것을 옹호할 수 있는 사람은 보이지 않습니다. 마일리지가 다를 수 있습니다.

따라서 내 트레이드오프에는 보안 및 SDK를 손상시키는 대신 반사로 JUnit을 복잡하게 만드는 것이 포함됩니다.

Community Wiki

private 메소드는 public 메소드에 의해 호출되므로 public 메소드에 대한 입력은 해당 public 메소드에 의해 호출되는 private 메소드도 테스트해야 합니다. 공개 방법이 실패하면 비공개 방법의 실패일 수 있습니다.

Community Wiki

Spring Framework에서 다음 메소드를 사용하여 개인 메소드를 테스트할 수 있습니다.

 ReflectionTestUtils.invokeMethod()

예를 들어:

 ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

Community Wiki

내가 사용한 또 다른 접근 방식은 private 또는 protected를 패키징하도록 private 메서드를 변경한 다음 Google Guava 라이브러리 의 @VisibleForTesting 주석으로 보완하는 것입니다.

이것은 이 방법을 사용하는 모든 사람에게 주의를 기울이고 패키지에서도 직접 액세스하지 말라고 알려줍니다. 또한 테스트 클래스는 물리적 으로 동일한 패키지에 있을 필요는 없지만 테스트 폴더 아래의 동일한 패키지에 있어야 합니다.

예를 들어, 테스트할 메소드가 src/main/java/mypackage/MyClass.java 경우 테스트 호출은 src/test/java/mypackage/MyClassTest.java 합니다. 그렇게 하면 테스트 클래스의 테스트 메서드에 액세스할 수 있습니다.

Community Wiki

크고 기발한 클래스와 테스트 레거시 코드에, 종종 내가 지금 쓰고있는 한 개인 (또는 공용) 방법을 테스트 할 수있는 것이 많은 도움이 될 것입니다.

Java용 junitx.util.PrivateAccessor -package를 사용합니다. private 메소드와 private 필드에 접근하기 위한 많은 유용한 원 라이너.

 import junitx.util.PrivateAccessor; PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue); PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

Community Wiki

Java용 리플렉션을 사용하여 Cem Catikka의 솔루션을 시도한 결과, 여기에서 설명한 것보다 그의 솔루션이 더 우아한 솔루션이었다고 말해야 합니다. 그러나 리플렉션 사용에 대한 대안을 찾고 있고 테스트 중인 소스에 액세스할 수 있는 경우 여전히 옵션이 될 것입니다.

코드를 작성하기 전에 작은 테스트를 설계하려는 경우 특히 테스트 주도 개발 에서 클래스의 비공개 메서드를 테스트하는 데 장점이 있습니다.

비공개 멤버 및 메서드에 대한 액세스 권한이 있는 테스트를 만들면 특히 공개 메서드에만 액세스하여 대상으로 지정하기 어려운 코드 영역을 테스트할 수 있습니다. 공개 방법에 여러 단계가 포함된 경우 여러 비공개 방법으로 구성될 수 있으며 개별적으로 테스트할 수 있습니다.

장점:

• 더 미세한 단위까지 테스트 가능

단점:

• 테스트 코드는 소스 코드와 동일한 파일에 있어야 하므로 유지 관리가 더 어려울 수 있습니다.
• .class 출력 파일과 유사하게 소스 코드에 선언된 것과 동일한 패키지 내에 있어야 합니다.

그러나 지속적인 테스트를 위해 이 방법이 필요한 경우 전통적인 공개 방식으로 테스트할 수 있는 비공개 방법을 추출해야 한다는 신호일 수 있습니다.

다음은 이것이 어떻게 작동하는지에 대한 복잡한 예입니다.

 // Import statements and package declarations public class ClassToTest { private int decrement(int toDecrement) { toDecrement--; return toDecrement; } // Constructor and the rest of the class public static class StaticInnerTest extends TestCase { public StaticInnerTest(){ super(); } public void testDecrement(){ int number = 10; ClassToTest toTest= new ClassToTest(); int decremented = toTest.decrement(number); assertEquals(9, decremented); } public static void main(String[] args) { junit.textui.TestRunner.run(StaticInnerTest.class); } } }

내부 클래스는 ClassToTest$StaticInnerTest 로 컴파일됩니다.

참조: Java Tip 106: 재미와 이익을 위한 정적 내부 클래스

Community Wiki

다른 사람들이 말했듯이 ... 개인 방법을 직접 테스트하지 마십시오. 다음은 몇 가지 생각입니다.

1. 모든 방법을 작고 집중적으로 유지(테스트하기 쉽고 잘못된 것을 찾기 쉽습니다)
2. 코드 커버리지 도구를 사용하십시오. 나는 Cobertura를 좋아한다 (오 행복한 하루, 새로운 버전이 나온 것 같습니다!)

단위 테스트에서 코드 검사를 실행합니다. 메소드가 완전히 테스트되지 않은 경우 테스트에 추가하여 적용 범위를 늘리십시오. 100% 코드 커버리지를 목표로 하되 얻지 못할 수도 있음을 인식하십시오.

Community Wiki

private 메소드는 public 메소드에 의해 사용됩니다. 그렇지 않으면 죽은 코드입니다. 그렇기 때문에 public 메소드를 테스트하여 public 메소드의 예상 결과와 그에 따라 사용하는 private 메소드를 어설션합니다.

비공개 메서드 테스트는 공개 메서드에서 단위 테스트를 실행하기 전에 디버깅을 통해 테스트해야 합니다.

또한 테스트 주도 개발을 사용하여 디버깅할 수 있으며 모든 주장이 충족될 때까지 단위 테스트를 디버깅할 수 있습니다.

개인적으로 TDD를 사용하여 클래스를 만드는 것이 더 낫다고 생각합니다. 공개 메서드 스텁을 만든 다음 미리 정의된 모든 어설션으로 단위 테스트를 생성하여 코드를 작성하기 전에 메서드의 예상 결과를 결정합니다. 이렇게 하면 단위 테스트 어설션을 결과에 맞게 만드는 잘못된 경로를 따라가지 않습니다. 그러면 클래스가 강력해지고 모든 단위 테스트가 통과하면 요구 사항을 충족합니다.

Community Wiki

Spring을 사용하는 경우 ReflectionTestUtils 는 최소한의 노력으로 여기에서 도움이 되는 몇 가지 편리한 도구를 제공합니다. 예를 들어, 원하지 않는 public setter를 추가하지 않고 private 멤버에 대해 mock을 설정하려면:

 ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

Community Wiki

내키지 않거나 변경할 수 없는 기존 코드를 테스트하려는 경우 리플렉션이 좋은 선택입니다.

클래스의 디자인이 여전히 유연하고 개별적으로 테스트하고 싶은 복잡한 private 메서드가 있는 경우 별도의 클래스로 가져와서 해당 클래스를 별도로 테스트하는 것이 좋습니다. 이것은 원래 클래스의 공용 인터페이스를 변경할 필요가 없습니다. 내부적으로 도우미 클래스의 인스턴스를 만들고 도우미 메서드를 호출할 수 있습니다.

도우미 메서드에서 오는 어려운 오류 조건을 테스트하려면 한 단계 더 나아갈 수 있습니다. 도우미 클래스에서 인터페이스를 추출하고 공개 getter 및 setter를 원본 클래스에 추가하여 도우미 클래스(해당 인터페이스를 통해 사용됨)를 주입한 다음 도우미 클래스의 모의 버전을 원본 클래스에 주입하여 원본 클래스가 어떻게 작동하는지 테스트합니다. 도우미의 예외에 응답합니다. 이 접근 방식은 도우미 클래스도 테스트하지 않고 원래 클래스를 테스트하려는 경우에도 유용합니다.

Community Wiki

내부 구현을 변경할 때마다 클라이언트 코드(이 경우 테스트)를 깨뜨리기 때문에 private 메서드를 테스트하면 클래스의 캡슐화가 깨집니다.

따라서 개인 메서드를 테스트하지 마십시오.

Community Wiki

JUnit.org FAQ 페이지 의 답변:

하지만 꼭 해야 한다면...

JDK 1.3 이상을 사용하는 경우 PrivilegedAccessor 의 도움으로 액세스 제어 메커니즘을 전복하기 위해 리플렉션을 사용할 수 있습니다. 사용 방법에 대한 자세한 내용은 이 문서를 참조하십시오 .

JDK 1.6 이상을 사용하고 @Test로 테스트에 주석을 추가 하는 경우 Dp4j 를 사용하여 테스트 메서드에 리플렉션을 삽입할 수 있습니다. 사용 방법에 대한 자세한 내용은 이 테스트 스크립트를 참조하십시오.

추신: 저는 Dp4j 의 주요 기여자입니다. 도움이 필요하면 저 에게 물어보세요. :)

Community Wiki

코드를 변경할 수 없는 레거시 응용 프로그램의 개인 메서드를 테스트하려는 경우 Java에 대한 한 가지 옵션은 jMockit입니다 . 이 옵션을 사용하면 클래스에 대해 비공개인 경우에도 객체에 대한 모의를 만들 수 있습니다.

Community Wiki

나는 개인적인 방법을 테스트하지 않는 경향이 있습니다. 거기에는 광기가 있습니다. 개인적으로, 공개적으로 노출된 인터페이스(보호 및 내부 메서드 포함)만 테스트해야 한다고 생각합니다.

Community Wiki

JUnit을 사용하는 경우 junit-addons를 살펴보십시오. Java 보안 모델을 무시하고 개인 메서드 및 속성에 액세스하는 기능이 있습니다.

Community Wiki

코드를 약간 리팩토링하는 것이 좋습니다. 코드를 테스트하기 위해 리플렉션이나 다른 종류의 사용에 대해 생각해야 할 때 코드에 문제가 있는 것입니다.

다양한 유형의 문제를 언급하셨습니다. 개인 필드부터 시작하겠습니다. 개인 필드의 경우 새 생성자를 추가하고 거기에 필드를 삽입했을 것입니다. 대신:

 public class ClassToTest { private final String first = "first"; private final List<String> second = new ArrayList<>(); ... }

나는 이것을 사용했을 것입니다 :

 public class ClassToTest { private final String first; private final List<String> second; public ClassToTest() { this("first", new ArrayList<>()); } public ClassToTest(final String first, final List<String> second) { this.first = first; this.second = second; } ... }

이것은 일부 레거시 코드에서도 문제가 되지 않습니다. 오래된 코드는 빈 생성자를 사용할 것이고, 나에게 묻는다면 리팩토링된 코드가 더 깔끔해 보일 것이고, 리플렉션 없이 테스트에서 필요한 값을 주입할 수 있을 것이다.

이제 개인 방법에 대해. 내 개인적인 경험에 따르면 테스트를 위해 개인 메서드를 스텁해야 하는 경우 해당 메서드는 해당 클래스에서 아무 관련이 없습니다. 이 경우 일반적인 패턴 Callable 과 같은 인터페이스 내 에서 래핑 한 다음 생성자에서도 해당 인터페이스를 전달하는 것입니다(여러 생성자 트릭 사용).

 public ClassToTest() { this(...); } public ClassToTest(final Callable<T> privateMethodLogic) { this.privateMethodLogic = privateMethodLogic; }

내가 쓴 대부분은 의존성 주입 패턴처럼 보입니다. 내 개인적인 경험으로는 테스트하는 동안 정말 유용하며, 이런 종류의 코드가 더 깨끗하고 유지 관리가 더 쉬울 것이라고 생각합니다. 중첩 클래스에 대해서도 마찬가지입니다. 중첩된 클래스에 무거운 논리가 포함된 경우 패키지 개인 클래스로 이동하고 이를 필요로 하는 클래스에 주입하는 것이 좋습니다.

레거시 코드를 리팩토링하고 유지 관리하는 동안 사용한 몇 가지 다른 디자인 패턴도 있지만 모두 테스트할 코드의 경우에 따라 다릅니다. 리플렉션을 사용하는 것은 대부분 문제가 되지 않지만, 모든 배포 전에 과도하게 테스트되고 테스트가 실행되는 엔터프라이즈 애플리케이션이 있으면 모든 것이 정말 느려집니다.

세터 주입도 있지만 사용하지 않는 것이 좋습니다. 나는 생성자를 고수하고 정말로 필요할 때 모든 것을 초기화하고 필요한 종속성을 주입할 가능성을 남겨두는 것이 좋습니다.

Community Wiki

예를 보려면 아래를 참조하십시오.

다음 import 문을 추가해야 합니다.

 import org.powermock.reflect.Whitebox;

이제 아래와 같이 private 메소드, 호출할 메소드 이름, 추가 매개변수가 있는 객체를 직접 전달할 수 있습니다.

 Whitebox.invokeMethod(obj, "privateMethod", "param1");

Community Wiki

PowerMockito는 이를 위해 만들어졌습니다. 메이븐 의존성 사용

 <dependency> <groupId>org.powermock</groupId> <artifactId>powermock-core</artifactId> <version>2.0.7</version> <scope>test</scope> </dependency>

그럼 당신은 할 수 있습니다

 import org.powermock.reflect.Whitebox; ... MyClass sut = new MyClass(); SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);

Community Wiki

다음은 개인 필드를 테스트하는 일반적인 기능입니다.

 protected <F> F getPrivateField(String fieldName, Object obj) throws NoSuchFieldException, IllegalAccessException { Field field = obj.getClass().getDeclaredField(fieldName); field.setAccessible(true); return (F)field.get(obj); }

Community Wiki

private 메소드는 같은 클래스 내에서만 접근할 수 있습니다. 따라서 테스트 클래스에서 대상 클래스의 "비공개" 메서드를 테스트할 방법이 없습니다. 탈출구는 단위 테스트를 수동으로 수행하거나 방법을 "비공개"에서 "보호됨"으로 변경할 수 있다는 것입니다.

그런 다음 보호된 메서드는 클래스가 정의된 동일한 패키지 내에서만 액세스할 수 있습니다. 따라서 대상 클래스의 보호된 메서드를 테스트한다는 것은 대상 클래스와 동일한 패키지에 테스트 클래스를 정의해야 함을 의미합니다.

위의 모든 것이 요구 사항에 맞지 않으면 리플렉션 방식 을 사용하여 private 메서드에 액세스합니다.

Community Wiki

위의 많은 사람들이 제안한 것처럼 좋은 방법은 공용 인터페이스를 통해 테스트하는 것입니다.

이 작업을 수행하는 경우 코드 검사 도구(예: Emma)를 사용하여 비공개 메서드가 실제로 테스트에서 실행되고 있는지 확인하는 것이 좋습니다.

Community Wiki

오늘 저는 개인 메서드와 필드를 테스트하는 데 도움이 되는 Java 라이브러리를 푸시했습니다. Android를 염두에 두고 설계되었지만 실제로 모든 Java 프로젝트에 사용할 수 있습니다.

개인 메서드나 필드 또는 생성자가 포함된 코드가 있는 경우 BoundBox 를 사용할 수 있습니다. 그것은 당신이 찾고있는 것을 정확히 수행합니다. 다음은 테스트하기 위해 Android 활동의 두 개인 필드에 액세스하는 테스트의 예입니다.

 @UiThreadTest public void testCompute() { // Given boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity()); // When boundBoxOfMainActivity.boundBox_getButtonMain().performClick(); // Then assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText()); }

BoundBox를 사용하면 개인/보호 필드, 메서드 및 생성자를 쉽게 테스트할 수 있습니다. 상속에 의해 숨겨진 항목에 액세스할 수도 있습니다. 실제로 BoundBox는 캡슐화를 중단합니다. 리플렉션을 통해 모든 것에 액세스할 수 있지만 모든 것은 컴파일 타임에 확인됩니다.

일부 레거시 코드를 테스트하는 데 이상적입니다. 주의해서 사용하십시오. ;)

https://github.com/stephanenicolas/boundbox

Community Wiki

먼저 이 질문을 던지겠습니다. 왜 개인 회원에게 격리 테스트가 필요한가요? 공개 표면과 별도로 테스트해야 할 정도로 복잡한 동작을 제공하는 것이 그렇게 복잡합니까? '코드 줄' 테스트가 아니라 단위 테스트입니다. 작은 일에 땀을 흘리지 마십시오.

이 private 멤버가 각각 복잡성이 큰 '단위'가 될 만큼 충분히 크면 이러한 private 멤버를 이 클래스에서 리팩토링하는 것을 고려하십시오.

리팩토링이 부적절하거나 실행 불가능한 경우 전략 패턴을 사용하여 단위 테스트 중에 이러한 비공개 멤버 함수/멤버 클래스에 대한 액세스를 대체할 수 있습니까? 단위 테스트에서 전략은 추가 유효성 검사를 제공하지만 릴리스 빌드에서는 단순한 통과가 됩니다.

Community Wiki

나는 최근에 이 문제가 있었고 두 가지 예인 Java 리플렉션 API를 명시적으로 사용하는 문제를 피하는 Picklock 이라는 작은 도구를 작성했습니다.

메서드 호출, 예를 들어 private void method(String s) - Java 리플렉션에 의해

 Method method = targetClass.getDeclaredMethod("method", String.class); method.setAccessible(true); return method.invoke(targetObject, "mystring");

메서드 호출, 예를 들어 private void method(String s) - Picklock에 의해

 interface Accessible { void method(String s); } ... Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class); a.method("mystring");

설정 필드, 예를 들어 private BigInteger amount; - 자바 리플렉션에 의해

 Field field = targetClass.getDeclaredField("amount"); field.setAccessible(true); field.set(object, BigInteger.valueOf(42));

설정 필드, 예를 들어 private BigInteger amount; - Picklock으로

 interface Accessible { void setAmount(BigInteger amount); } ... Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class); a.setAmount(BigInteger.valueOf(42));

Community Wiki

출처 : http:www.stackoverflow.com/questions/34571/how-do-i-test-a-private-function-or-a-class-that-has-private-methods-fields-or