Pruebas unitarias de métodos privados en C++

Question 1

Estoy en el proceso de escribir algunas pruebas unitarias. En particular, quiero probar algunos métodos privados.

Hasta ahora, he llegado a usar.

#define private public

Pero no estoy contento con esto, ya que destruirá toda la encapsulación desde el punto de vista de la prueba unitaria.

¿Qué métodos utiliza para realizar pruebas unitarias de métodos privados?

Question 2

En lugar de lo desagradable #define truco que mencionas en la pregunta, un mecanismo más limpio es hacer que la prueba sea un amigo de la clase bajo prueba. Esto permite que el código de prueba (y solo el código de prueba) acceda a los privados, mientras los protege de todo lo demás.

Sin embargo, es preferible probar a través de la interfaz pública. Si su clase X tiene mucho código en las funciones de miembros privados, entonces podría valer la pena extraer una nueva clase Y que se usa para la implementación de la clase X. Esta nueva clase Y se puede probar a través de su interfaz pública, sin exponer su uso a los clientes de clase X.

Question 3

Si está usando Google Test, puede usar AMIGO_TEST para declarar fácilmente su dispositivo de prueba como amigo de la clase bajo prueba.

Y ya sabes, si probar funciones privadas fuera inequívocamente malo como decían algunas de las otras respuestas, entonces probablemente no estaría integrado en Google Test.

Puede leer más sobre cuándo probar funciones privadas es bueno o malo en esta respuesta.

Question 4

Si los métodos son lo suficientemente complejos como para justificar la prueba de forma aislada, refactorícelos en su(s) propia(s) clase(s) y pruébelos a través de su(s) interfaz(es) pública(s). Luego úsalos de forma privada en la clase original.

Question 5

Haga la clase de prueba como amigo de la clase original. Esta declaración de amistad estará dentro del #define UNIT_TEST bandera.

class To_test_class {
   #ifdef UNIT_TEST
     friend test_class;
   #endif
}

Ahora, para su prueba unitaria, compilará el código con flag -DUNIT_TEST. De esta manera podrá probar la función privada.

Ahora su código de prueba de unidad no será enviado al entorno de producción, ya que UNIT_TEST la bandera será falsa. Por lo tanto, el código sigue siendo seguro.

Además, no necesitará ninguna biblioteca especial para las pruebas unitarias.

Question 6

Sé que esta es una pregunta anterior, pero parece que nadie ha compartido el método relativamente bueno que prefiero, así que aquí va:

Cambie el método desde el que desea probar private a protected. Para otras clases, el método seguirá siendo privatepero ahora puede derivar una clase de “prueba” de su clase base que expone la funcionalidad privada que desea probar.

He aquí un ejemplo mínimo:

class BASE_CLASS {
  protected:
    int your_method(int a, int b);
};

class TEST_CLASS : public BASE_CLASS {
  public:
    int your_method(int a, int b) {
      return BASE_CLASS::your_method(a, b);
    }
}

Por supuesto, tendrá que actualizar sus pruebas unitarias para ejecutar sus pruebas en la clase derivada en lugar de la clase base, pero después de eso, cualquier cambio realizado en la clase base se reflejará automáticamente en la clase de “prueba”.

Question 7

Después de muchas horas, esto es lo que decidí que sería la mejor solución para aquellos que quieren probar sus funciones privadas. Esta es una combinación de respuestas de Max DeLiso y Miloš.

Si estás usando boost::unidad-prueba entonces hay una solución fácil y elegante.

Usar protected en lugar de private en tus clases

/* MyClass.hpp */

class MyClass {

protected:
    int test() {
        return 1;
    }
};

Crear un accesorio:

/* TestMyClass.cpp */

class F : public MyClass {};


BOOST_FIXTURE_TEST_SUITE(SomeTests, F)

// use any protected methods inside your tests
BOOST_AUTO_TEST_CASE(init_test)
{
    BOOST_CHECK_EQUAL( test(), 1 );
}
BOOST_AUTO_TEST_SUITE_END()

De esta manera puede utilizar libremente cualquiera de los MyClass funciones sin #define private public o agregando amigos a tu clase!

Question 8

El truco de definición es una idea horrible. Reescribir arbitrariamente su código con el preprocesador cuando va a compilarlo nunca es prudente.

Ahora, como varias personas ya han mencionado, es discutible si debería probar métodos privados. Pero esto no cubre el caso en el que intencionalmente ha ocultado constructores para restringir la creación de instancias a ciertos ámbitos, o algunos otros casos más esotéricos.

Además, no puede ser amigo de un espacio de nombres y la “amistad” no se hereda en C ++, por lo que, según el marco de prueba de su unidad, podría tener problemas. Afortunadamente, si está utilizando Boost.Test, hay una solución elegante para este problema en forma de accesorios.

http://www.boost.org/doc/libs/1_52_0/libs/test/doc/html/utf/user-guide/fixture/per-test-case.html

Puede hacer amigo del accesorio y hacer que cree instancias de todas las instancias que usa en las funciones de prueba de su unidad, declarándolas como estáticas para el accesorio y con alcance de módulo. Si está utilizando un espacio de nombres, no se preocupe, puede simplemente declarar su accesorio dentro del espacio de nombres y sus casos de prueba fuera del espacio de nombres, y luego usar el operador de resolución de alcance para llegar a los miembros estáticos.

El BOOST_FIXTURE_TEST_CASE macro se encargará de instanciar y derribar su dispositivo por usted.

¿Ha sido útil esta solución?