2010-03-07 21 views

Respuesta

26

Prueba esto (directamente de documentos de prueba Google ...):

FRIEND_TEST(TestCaseName, TestName); 

Por ejemplo:

// foo.h 
#include <gtest/gtest_prod.h> 

// Defines FRIEND_TEST. 
class Foo { 
    ... 
private: 
    FRIEND_TEST(FooTest, BarReturnsZeroOnNull); 
    int Bar(void* x); 
}; 

// foo_test.cc 
... 
TEST(FooTest, BarReturnsZeroOnNull) { 
    Foo foo; 
    EXPECT_EQ(0, foo.Bar(NULL)); 
    // Uses Foo's private member Bar(). 
} 
+0

¿Qué pasa si tengo cualquier otro ensayo, por ejemplo BarReturnsOneOnSth. ¿Debo agregar otra declaración FRIEND_TEST para esa prueba también? – pajton

+1

Sí. Cada prueba es técnicamente una clase, y necesitas hacerte amigo de ellas de a una por vez. – hobbit

+15

¿Cómo puedo hacerlo de una manera que no me obligue a incluir los archivos de encabezado de googletest en el archivo de encabezado con la clase 'Foo'? –

19

Sé que esto es viejo, pero yo estaba buscando la misma respuesta hoy. "gtest_prod.h" simplemente introduce una macro simple para hacer referencia a las clases de prueba.

#define FRIEND_TEST(test_case_name, test_name)\ 
friend class test_case_name##_##test_name##_Test 

Así FRIEND_TEST(FooTest, BarReturnsZeroOnNull); es equivalente a:

friend class FooTest_BarReturnsZeroOnNull_Test; 

Esto funciona porque cada prueba es su propia clase como se mencionó en la respuesta anterior.

+0

@DaveRuske No explique su edición en la edición en sí. Para eso es el resumen de edición. Si el problema es el límite de 6 caracteres, puede agregar un '' en algún lugar del cuerpo ('' es un comentario y, por lo tanto, no estará visible). –

0

Una estrategia mucho mejor es no permitir que las pruebas amigo entre las pruebas unitarias.

Permitir que las pruebas de acceso a los miembros privados amigo conducirán a una base de código que es difícil de mantener. Las pruebas que se rompen cada vez que se refactorizan los detalles internos de la implementación de un componente no son lo que usted desea. Si se realiza un esfuerzo adicional para obtener un diseño donde los componentes se puedan probar a través de su interfaz pública, obtendrá pruebas que solo necesitan actualización cada vez que se actualice la interfaz pública de un componente.

pruebas que dependen de gtest/gtest_prod.h deben ser vistos como un signo de un mal diseño.

+1

entiendo que esto es controversial (esperemos que se obtuvo una especie de "respuesta controvertido" insignia ), pero estoy contento de que alguien hizo subir este punto de vista. ¡Muchos están de acuerdo con @Martin en esto! https://dzone.com/articles/principles-creating – pestophagous

Cuestiones relacionadas