¿Cómo pruebo una función privada o una clase que tiene métodos privados, campos o clases internas?

¿Cómo pruebo la unidad (usando xUnit) una clase que tiene métodos privados internos, campos o clases anidadas? ¿O una función que se hace privada al tener un enlace interno ( staticen C / C ++) o está en un espacio de nombres privado ( anónimo )?

Parece malo cambiar el modificador de acceso para un método o función solo para poder ejecutar una prueba.

Actualizar:

Unos 10 años más tarde, tal vez la mejor manera de probar un método privado, o cualquier miembro inaccesible, es a través @Jailbreakdel marco de Manifold .

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

De esta manera, su código sigue siendo seguro para escribir y legible. Sin compromisos de diseño, sin métodos de sobreexposición y campos por el bien de las pruebas.

Si tienes algo de un legado aplicación Java y no puede cambiar la visibilidad de sus métodos, la mejor manera de probar métodos privados es usar la reflexión .

Internamente estamos usando ayudantes para obtener / establecer privatey private staticvariables, así como invocarprivate y private staticmétodos. Los siguientes patrones le permitirán hacer prácticamente cualquier cosa relacionada con los métodos y campos privados. Por supuesto, no puede cambiar las private static finalvariables a través de la reflexión.

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

Y para campos:

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

Notas:
1. le TargetClass.getDeclaredMethod(methodName, argClasses)permite buscar privatemétodos. Lo mismo se aplica getDeclaredField.
2. Se setAccessible(true)requiere jugar con los soldados.

La mejor manera de probar un método privado es a través de otro método público. Si esto no se puede hacer, entonces una de las siguientes condiciones es verdadera:

1. El método privado es código muerto
2. Hay un olor a diseño cerca de la clase que está probando
3. El método que está intentando probar no debe ser privado.

Cuando tengo métodos privados en una clase que son lo suficientemente complicados como para sentir la necesidad de probarlos directamente, es un olor a código: mi clase es demasiado complicada.

Mi enfoque habitual para abordar estos problemas es descifrar una nueva clase que contenga los bits interesantes. A menudo, este método y los campos con los que interactúa, y quizás otro método o dos se pueden extraer en una nueva clase.

La nueva clase expone estos métodos como 'públicos', por lo que son accesibles para pruebas unitarias. Las clases nuevas y antiguas ahora son más simples que la clase original, lo cual es genial para mí (¡necesito mantener las cosas simples o me pierdo!).

¡Tenga en cuenta que no estoy sugiriendo que las personas creen clases sin usar su cerebro! El punto aquí es utilizar las fuerzas de las pruebas unitarias para ayudarlo a encontrar buenas clases nuevas.

He utilizado la reflexión para hacer esto para Java en el pasado, y en mi opinión fue un gran error.

Estrictamente hablando, no debe escribir pruebas unitarias que prueben directamente métodos privados. Lo que deberias probar es el contrato público que la clase tiene con otros objetos; nunca debes probar directamente las partes internas de un objeto. Si otro desarrollador quiere hacer un pequeño cambio interno en la clase, lo que no afecta el contrato público de las clases, entonces él / ella tiene que modificar su prueba basada en la reflexión para asegurarse de que funcione. Si hace esto repetidamente a lo largo de un proyecto, las pruebas unitarias dejan de ser una medida útil del estado del código y comienzan a convertirse en un obstáculo para el desarrollo y una molestia para el equipo de desarrollo.

Lo que recomiendo hacer en su lugar es utilizar una herramienta de cobertura de código como Cobertura, para garantizar que las pruebas unitarias que escriba proporcionen una cobertura decente del código en métodos privados. De esa manera, usted prueba indirectamente lo que están haciendo los métodos privados y mantiene un mayor nivel de agilidad.

De este artículo: Prueba de métodos privados con JUnit y SuiteRunner (Bill Venners), básicamente tiene 4 opciones:

1. No pruebes métodos privados.
2. Dar acceso al paquete de métodos.
3. Use una clase de prueba anidada.
4. Usa la reflexión.

Generalmente, una prueba de unidad está destinada a ejercer la interfaz pública de una clase o unidad. Por lo tanto, los métodos privados son detalles de implementación que no esperaría probar explícitamente.

Solo dos ejemplos de dónde me gustaría probar un método privado:

1. Rutinas de descifrado : no quisiera hacerlas visibles para que cualquiera las vea solo por el simple hecho de probarlas, de lo contrario, cualquiera puede usarlas para descifrarlas. Pero son intrínsecos al código, complicados y deben funcionar siempre (la excepción obvia es la reflexión que se puede usar para ver incluso métodos privados en la mayoría de los casos, cuando SecurityManagerno está configurado para evitar esto).
2. Creación de un SDK para consumo comunitario. Aquí el público adquiere un significado completamente diferente, ya que este es un código que todo el mundo puede ver (no solo interno a mi aplicación). Pongo código en métodos privados si no quiero que los usuarios del SDK lo vean. No veo esto como un olor a código, sino simplemente cómo funciona la programación del SDK. Pero, por supuesto, todavía necesito probar mis métodos privados, y es donde realmente vive la funcionalidad de mi SDK.

Entiendo la idea de probar solo el "contrato". Pero no veo que uno pueda abogar por no probar el código; su millaje puede variar.

Entonces, mi compensación implica complicar los JUnits con la reflexión, en lugar de comprometer mi seguridad y SDK.

Los métodos privados son llamados por un método público, por lo que las entradas a sus métodos públicos también deben probar los métodos privados que son llamados por esos métodos públicos. Cuando falla un método público, eso podría ser un error en el método privado.

Otro enfoque que he usado es cambiar un método privado para empaquetar privado o protegido y luego complementarlo con la anotación @VisibleForTesting de la biblioteca Google Guava.

Esto le indicará a cualquiera que use este método que tenga cuidado y no acceda directamente, incluso en un paquete. Además, una clase de prueba no necesita estar físicamente en el mismo paquete , sino en el mismo paquete debajo de la carpeta de prueba .

Por ejemplo, si hay un método para probar, src/main/java/mypackage/MyClass.javaentonces su llamada de prueba debe realizarse src/test/java/mypackage/MyClassTest.java. De esa manera, tienes acceso al método de prueba en tu clase de prueba.

Para probar el código heredado con clases grandes y extravagantes, a menudo es muy útil poder probar el método privado (o público) que estoy escribiendo en este momento .

Yo uso el paquete junitx.util.PrivateAccessor para Java. Un montón de frases útiles para acceder a métodos privados y campos privados.

import junitx.util.PrivateAccessor;

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

En Spring Framework , puede probar métodos privados utilizando este método:

ReflectionTestUtils.invokeMethod()

Por ejemplo:

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

Después de haber probado la solución de Cem Catikkas usando la reflexión para Java, debo decir que fue una solución más elegante que la que he descrito aquí. Sin embargo, si está buscando una alternativa al uso de la reflexión y tiene acceso a la fuente que está probando, esta seguirá siendo una opción.

Existe la posibilidad de probar métodos privados de una clase, particularmente con el desarrollo basado en pruebas , en el que le gustaría diseñar pequeñas pruebas antes de escribir cualquier código.

Crear una prueba con acceso a miembros y métodos privados puede probar áreas de código que son difíciles de enfocar específicamente con acceso solo a métodos públicos. Si un método público tiene varios pasos involucrados, puede consistir en varios métodos privados, que luego pueden probarse individualmente.

Ventajas:

• Puede probar a una granularidad más fina

Desventajas

• El código de prueba debe residir en el mismo archivo que el código fuente, lo que puede ser más difícil de mantener
• De manera similar con los archivos de salida .class, deben permanecer dentro del mismo paquete que el declarado en el código fuente

Sin embargo, si las pruebas continuas requieren este método, puede ser una señal de que deben extraerse los métodos privados, que podrían probarse de la manera tradicional y pública.

Aquí hay un ejemplo complicado de cómo funcionaría esto:

// 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);
        }
    }
}

La clase interna se compilaría a ClassToTest$StaticInnerTest.

Ver también: Java Tip 106: Clases internas estáticas para diversión y ganancias

Como otros han dicho ... no pruebes métodos privados directamente. Aquí hay algunos pensamientos:

1. Mantenga todos los métodos pequeños y enfocados (fácil de probar, fácil de encontrar lo que está mal)
2. Use herramientas de cobertura de código. Me gusta Cobertura (¡feliz día, parece que ya salió una nueva versión!)

Ejecute la cobertura del código en las pruebas unitarias. Si ve que los métodos no se prueban completamente, agréguelos a las pruebas para aumentar la cobertura. Apunte a una cobertura de código del 100%, pero tenga en cuenta que probablemente no la obtendrá.

Los métodos privados son consumidos por los públicos. De lo contrario, son código muerto. Es por eso que prueba el método público, afirmando los resultados esperados del método público y, por lo tanto, los métodos privados que consume.

La prueba de los métodos privados debe probarse mediante depuración antes de ejecutar las pruebas unitarias en los métodos públicos.

También se pueden depurar mediante el desarrollo basado en pruebas, depurando las pruebas unitarias hasta que se cumplan todas sus afirmaciones.

Personalmente, creo que es mejor crear clases con TDD; crear los resguardos de métodos públicos, luego generar pruebas unitarias con todas las aserciones definidas de antemano, de modo que el resultado esperado del método se determine antes de codificarlo. De esta manera, no va por el camino equivocado de hacer que las afirmaciones de la prueba unitaria se ajusten a los resultados. Su clase es robusta y cumple con los requisitos cuando pasan todas las pruebas de su unidad.

Si usa Spring, ReflectionTestUtils proporciona algunas herramientas útiles que ayudan aquí con un mínimo esfuerzo. Por ejemplo, para configurar un simulacro en un miembro privado sin verse obligado a agregar un setter público indeseable:

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

Si intenta probar el código existente que es reacio o no puede cambiar, la reflexión es una buena opción.

Si el diseño de la clase sigue siendo flexible, y tiene un método privado complicado que le gustaría probar por separado, le sugiero que lo saque a una clase separada y pruebe esa clase por separado. Esto no tiene que cambiar la interfaz pública de la clase original; internamente puede crear una instancia de la clase auxiliar y llamar al método auxiliar.

Si desea probar condiciones de error difíciles provenientes del método auxiliar, puede ir un paso más allá. Extraiga una interfaz de la clase auxiliar, agregue un captador y definidor público a la clase original para inyectar la clase auxiliar (utilizada a través de su interfaz), y luego inyecte una versión simulada de la clase auxiliar en la clase original para probar cómo funciona la clase original responde a excepciones del ayudante. Este enfoque también es útil si desea probar la clase original sin probar también la clase auxiliar.

Probar métodos privados rompe la encapsulación de su clase porque cada vez que cambia la implementación interna se rompe el código del cliente (en este caso, las pruebas).

Así que no pruebes métodos privados.

La respuesta de la página de preguntas frecuentes de JUnit.org :

Pero si debes ...

Si está utilizando JDK 1.3 o superior, puede usar la reflexión para subvertir el mecanismo de control de acceso con la ayuda del PrivilegedAccessor . Para obtener detalles sobre cómo usarlo, lea este artículo .

Si está utilizando JDK 1.6 o superior y anota sus pruebas con @Test, puede usar Dp4j para inyectar reflejo en sus métodos de prueba. Para obtener detalles sobre cómo usarlo, consulte este script de prueba .

PS Soy el principal contribuyente a Dp4j , pregunto yo si necesita ayuda. :)

Si desea probar métodos privados de una aplicación heredada donde no puede cambiar el código, una opción para Java es jMockit , que le permitirá crear simulacros para un objeto incluso cuando son privados para la clase.

Tiendo a no probar métodos privados. Ahí yace la locura. Personalmente, creo que solo debe probar sus interfaces expuestas públicamente (y eso incluye métodos protegidos e internos).

Si está usando JUnit, eche un vistazo a junit-addons . Tiene la capacidad de ignorar el modelo de seguridad de Java y acceder a métodos y atributos privados.

Te sugiero que refactorices un poco tu código. Cuando tiene que comenzar a pensar en usar la reflexión u otro tipo de cosas, solo para probar su código, algo va mal con su código.

Mencionaste diferentes tipos de problemas. Comencemos con los campos privados. En el caso de campos privados, habría agregado un nuevo constructor e inyectado campos en eso. En lugar de esto:

public class ClassToTest {

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

Hubiera usado esto:

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;
    }
    ...
}

Esto no será un problema incluso con algún código heredado. El código anterior usará un constructor vacío, y si me preguntas, el código refactorizado se verá más limpio y podrás inyectar los valores necesarios en la prueba sin reflexión.

Ahora sobre métodos privados. En mi experiencia personal, cuando tienes que colocar un método privado para probar, ese método no tiene nada que ver en esa clase. Un patrón común, en ese caso, sería envolver dentro de una interfaz, como Callabley luego pasar esa interfaz también en el constructor (con ese truco de constructor múltiple):

public ClassToTest() {
    this(...);
}

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

Casi todo lo que escribí parece que es un patrón de inyección de dependencia. En mi experiencia personal, es realmente útil durante las pruebas, y creo que este tipo de código es más limpio y será más fácil de mantener. Yo diría lo mismo sobre las clases anidadas. Si una clase anidada contiene una lógica pesada, sería mejor si la hubiera movido como una clase privada de paquete y la hubiera inyectado en una clase que la necesita.

También hay varios otros patrones de diseño que he usado al refactorizar y mantener el código heredado, pero todo depende de los casos de su código para probar. El uso de la reflexión en su mayoría no es un problema, pero cuando tienes una aplicación empresarial que está muy probada y las pruebas se ejecutan antes de cada implementación, todo se vuelve realmente lento (es molesto y no me gusta ese tipo de cosas).

También hay una inyección de setter, pero no recomendaría usarla. Mejor me quedo con un constructor e inicializo todo cuando sea realmente necesario, dejando la posibilidad de inyectar las dependencias necesarias.

Solo se puede acceder a un método privado dentro de la misma clase. Por lo tanto, no hay forma de probar un método "privado" de una clase objetivo desde ninguna clase de prueba. Una salida es que puede realizar pruebas unitarias manualmente o puede cambiar su método de "privado" a "protegido".

Y luego solo se puede acceder a un método protegido dentro del mismo paquete donde se define la clase. Por lo tanto, probar un método protegido de una clase objetivo significa que necesitamos definir su clase de prueba en el mismo paquete que la clase objetivo.

Si todo lo anterior no cumple con sus requisitos, use la forma de reflexión para acceder al método privado.

Como muchos han sugerido anteriormente, una buena manera es probarlos a través de sus interfaces públicas.

Si hace esto, es una buena idea usar una herramienta de cobertura de código (como Emma) para ver si sus métodos privados se están ejecutando de sus pruebas.

Aquí está mi función genérica para probar campos privados:

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);
}

Consulte a continuación para ver un ejemplo;

Se debe agregar la siguiente declaración de importación:

import org.powermock.reflect.Whitebox;

Ahora puede pasar directamente el objeto que tiene el método privado, el nombre del método que se va a llamar y los parámetros adicionales como se muestra a continuación.

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

Hoy, introduje una biblioteca Java para ayudar a probar métodos y campos privados. Ha sido diseñado con Android en mente, pero realmente se puede usar para cualquier proyecto Java.

Si tiene algún código con métodos privados o campos o constructores, puede usar BoundBox . Hace exactamente lo que estás buscando. A continuación se muestra un ejemplo de una prueba que accede a dos campos privados de una actividad de Android para probarla:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

BoundBox facilita la prueba de campos, métodos y constructores privados / protegidos. Incluso puedes acceder a cosas que están ocultas por herencia. De hecho, BoundBox rompe la encapsulación. Te dará acceso a todo eso a través de la reflexión, PERO todo se verifica en tiempo de compilación.

Es ideal para probar algunos códigos heredados. Úselo con cuidado. ;)

https://github.com/stephanenicolas/boundbox

Primero, haré esta pregunta: ¿Por qué sus miembros privados necesitan pruebas aisladas? ¿Son tan complejos y proporcionan comportamientos tan complicados que requieren pruebas aparte de la superficie pública? Es una prueba unitaria, no una prueba de "línea de código". No te preocupes por las cosas pequeñas.

Si son tan grandes, lo suficientemente grandes como para que estos miembros privados sean cada uno una 'unidad' de gran complejidad, considere refactorizar a tales miembros privados fuera de esta clase.

Si la refactorización es inapropiada o inviable, ¿puede usar el patrón de estrategia para reemplazar el acceso a estas funciones / clases de miembros privados cuando se realiza una prueba unitaria? Según la prueba unitaria, la estrategia proporcionaría una validación adicional, pero en las versiones de lanzamiento sería un paso simple.

Recientemente tuve este problema y escribí una pequeña herramienta, llamada Picklock , que evita los problemas de usar explícitamente la API de reflexión de Java, dos ejemplos:

Métodos de llamada, por ejemplo private void method(String s), por reflexión de Java

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

Métodos de llamada, por ejemplo private void method(String s), por Picklock

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

Configuración de campos, p private BigInteger amount;. Ej ., Por reflexión Java

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

Configuración de campos, por ejemplo private BigInteger amount;, por Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito está hecho para esto. Usar dependencia maven

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

Entonces puedes hacer

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