¿Cómo puedo probar métodos privados con DUnit?

Question

Tengo una clase que estoy probando unitariamente con DUnit. Tiene una serie de métodos algunos métodos públicos y métodos privados.

type 
    TAuth = class(TDataModule) 
    private 
    procedure PrivateMethod; 
    public 
    procedure PublicMethod; 
    end; 

Para escribir una prueba unitaria para esta clase, tengo que hacer que todos los métodos sean públicos.

¿Existe alguna manera diferente de declarar los métodos privados para poder probarlos pero no son públicos?

Answer 1

No es necesario que sean públicos. Protegido hará. Luego puede subtipificar la clase para las pruebas unitarias y explorar los métodos protegidos. Ejemplo:

type 
    TAuth = class(TDataModule) 
    protected 
    procedure MethodIWantToUnitTest; 
    public 
    procedure PublicMethod; 
    end; 

Ahora puede subtipo para su unidad de prueba:

interface 

uses 
    TestFramework, Classes, AuthDM; 

type 
    // Test methods for class TAuthDM 
    TestAuthDM = class(TTestCase) 
    // stuff 
    end; 

    TAuthDMTester = class(TAuthDM) 
    public 
    procedure MethodIWantToUnitTestMadePublic; 
    end; 

implementation 

procedure TAuthDMTester.MethodIWantToUnitTestMadePublic; 
begin 
    MethodIWantToUnitTest; 
end; 

Sin embargo, si los métodos que desea probar la unidad están haciendo las cosas tan íntimamente con el módulo de datos que no es seguro para tener algo más que privado, entonces realmente debería considerar refactorizar los métodos para segregar el código que necesita ser probado por unidades y el código que accede a las entrañas del módulo de datos.

Answer 2

recomiendo el libro "XUnit Test Patterns" por Gerard Meszaros:

Test-Specific Subclass

Pregunta: ¿Cómo podemos hacer que el código comprobable cuando necesitamos acceder a estado privada de la IVU ?

respuesta: Añadir métodos que exponen el estado o comportamiento que necesita la prueba a una subclase de la IVU.

... Si el sistema bajo prueba (SUT) no era diseñado específicamente para ser comprobable, podemos encontrar que la prueba no puede obtener acceso a Estado que debe inicializar o verificar en algún momento de la prueba.

El artículo también explica cuándo usarlo y qué riesgos conlleva.

Answer 3

Ponga el código de DUnit dentro de su unidad. A continuación, puede acceder a cualquier cosa que desee.

Answer 4

que es un poco hacky, pero me gusta usar esta directiva de compilación condicional:

{$IfNDef TEST} 
    private 
    {$EndIf} 

Su proyecto de prueba de unidad debe definir PRUEBA en project → conditional defines.

Sin una especificación de visibilidad, se publican. Cuidado: si la visibilidad privada no es la primera en la declaración de clase, obtendrá la definición anterior.Una forma más segura, pero más detallado y menos claro, sería:

private 
    {$IfDef TEST} 
    public 
    {$EndIf} 

Esto tiene algunas ventajas con respecto a la creación de subclases u otros enfoques:

• ninguna complejidad adicional: no hay clases adicionales en el código
• Nadie puede subclasificar y anular "erróneamente" su clase: conserva su arquitectura
• Cuando dice que un método está protegido, de alguna manera espera que se anule. Usted está diciendo esto para quién está leyendo su código. Un método protegido que no debe ser anulado confundirá a los lectores de su código, rompiendo mi primer principio de programación: "el código debe escribirse para ser leído por otros seres humanos".
• DUnit está en su propia unidad, no se incluye en todas partes
• No toca el sucio RTTI.

Creo que es una solución más clara y mejor que la respuesta seleccionada.

Cuando uso esto, también configuro el proyecto de prueba para colocar los objetos de compilación en un directorio diferente del proyecto principal. Esto evita que los binarios con la directiva TEST se mezclen con el otro código.

Answer 5

En general, cuando llego a esta situación, a menudo me doy cuenta de que estoy violando el principio de responsabilidad única. Por supuesto, no sé nada sobre su caso específico, pero QUIZÁ, que los métodos privados deben ser de su propia clase. El TAuth tendría una referencia a esta nueva clase en su sección privada.

Answer 6

Con Extended RTTI (Delphi 2010 y posteriores), la invocación de métodos privados a través de RTTI es otra opción. Esta solución es también la respuesta de primer nivel en How do I test a class that has private methods, fields or inner classes?

Answer 7

{$IFNDEF UNITEST} 
private 
{$ENDIF} 

solución simple, que casi no es un truco. Con frecuencia necesito probar métodos privados y esta técnica agrega la menor complicación posible.