GoogleTest: ¿Cómo omitir una prueba?

7 minutos de lectura

avatar de usuario
Usuario

Utilizando Google Test 1.6 (Windows 7, Visual Studio C++). ¿Cómo puedo desactivar una prueba determinada? (también conocido como ¿cómo puedo evitar que se ejecute una prueba). ¿Hay algo que pueda hacer además de comentar toda la prueba?

avatar de usuario
Factura

los documentos para la prueba de Google 1.7 sugerir:

Si tiene una prueba rota que no puede arreglar de inmediato, puede agregar la DISABLED_ prefijo de su nombre. Esto lo excluirá de la ejecución. Esto es mejor que comentar el código o usar #if 0ya que las pruebas deshabilitadas aún se compilan (y, por lo tanto, no se pudrirán).

Ejemplo de la documentación anterior:

// Tests that Foo does Abc.
TEST(FooTest, DISABLED_DoesAbc) { ... }

class DISABLED_BarTest : public testing::Test { ... };

// Tests that Bar does Xyz.
TEST_F(DISABLED_BarTest, DoesXyz) { ... }

  • acabo de encontrarlo también y filtros

    – Usuario

    26 de agosto de 2011 a las 17:01

  • @Bill, lo encontré justo antes de que publicaras tu comentario… (y también lo puse como respuesta). Luego eliminé mi comentario, pensando que estaba obsoleto… ¡pero esa es una información realmente buena! +1

    – Cirilo

    26 de agosto de 2011 a las 17:05


  • Pero deshabilitar no es saltar. Omitir es un estado temporal no disponible (como no estar conectado a Internet) y solo se detecta dinámicamente en la llamada de configuración. Solo lo menciono, ya que este es el resultado de Google n.º 1 11 años después.

    – Lotario

    7 abr a las 9:00

avatar de usuario
Cirilo

Tú también puedes ejecutar un subconjunto de pruebassegún la documentación:

Ejecución de un subconjunto de las pruebas

De forma predeterminada, un programa de prueba de Google ejecuta todas las pruebas que el usuario ha definido. A veces, desea ejecutar solo un subconjunto de las pruebas (por ejemplo, para depurar o verificar rápidamente un cambio). Si establece la variable de entorno GTEST_FILTER o la marca –gtest_filter en una cadena de filtro, Google Test solo ejecutará las pruebas cuyos nombres completos (en forma de TestCaseName.TestName) coincidan con el filtro.

El formato de un filtro es una lista de patrones comodín separados por ‘:’ (llamados patrones positivos) seguido opcionalmente por un ‘-‘ y otra lista de patrones separados por ‘:’ (llamados patrones negativos). Una prueba coincide con el filtro si y solo si coincide con cualquiera de los patrones positivos pero no coincide con ninguno de los patrones negativos.

Un patrón puede contener ‘*’ (coincide con cualquier cadena) o ‘?’ (coincide con cualquier carácter individual). Por comodidad, el filtro ‘*-Patrón Negativo’ también se puede escribir como ‘-Patrón Negativo’.

Por ejemplo:

./foo_test Has no flag, and thus runs all its tests.
./foo_test --gtest_filter=* Also runs everything, due to the single match-everything * value.
./foo_test --gtest_filter=FooTest.* Runs everything in test case FooTest.
./foo_test --gtest_filter=*Null*:*Constructor* Runs any test whose full name contains either "Null" or "Constructor".
./foo_test --gtest_filter=-*DeathTest.* Runs all non-death tests.
./foo_test --gtest_filter=FooTest.*-FooTest.Bar Runs everything in test case FooTest except FooTest.Bar. 

No es la solución más bonita, pero funciona.

  • En mi caso, necesito poner la condición de filtrado entre comillas ya que * se reconoce como un comodín.

    – thd

    21 abr a las 9:51

avatar de usuario
Pedro Bloomfield

Ahora puede utilizar el GTEST_SKIP() macro para omitir condicionalmente una prueba en tiempo de ejecución. Por ejemplo:

TEST(Foo, Bar)
{
    if (blah)
        GTEST_SKIP();

    ...
}

Tenga en cuenta que esto es muy característica reciente por lo que es posible que deba actualizar su biblioteca de GoogleTest para usarla.

  • Esta función aún no se ha lanzado. Es poco probable que se incluya en una rama 1.8.x, ya que allí solo se aceptan correcciones. 1.9 aún no está disponible, ni siquiera se ha anunciado en este momento.

    – ocroqueta

    14 de abril de 2019 a las 7:11

  • GTEST_SKIP() está disponible desde 1.10.0.

    – mattdibi

    25 de marzo de 2020 a las 17:02

  • Lamentablemente, la documentación aún es escasa al respecto. parece que también hay GTEST_SKIP_("some message") (tenga en cuenta el guión bajo final)

    – Brandlingo

    16 de abril de 2020 a las 15:27

  • Es #define GTEST_SKIP() GTEST_SKIP_("") en gtest.h para permitir un mensaje de omisión opcional.

    – sebkraemer

    18 de noviembre de 2020 a las 7:47

avatar de usuario
asutosh

Esta es la expresión para incluir pruebas cuyos nombres tengan las cadenas foo1 o foo2 y excluir las pruebas cuyos nombres tengan las cadenas bar1 o bar2:

--gtest_filter=*foo1*:*foo2*-*bar1*:*bar2*

Yo prefiero hacerlo en código:

// Run a specific test only
//testing::GTEST_FLAG(filter) = "MyLibrary.TestReading"; // I'm testing a new feature, run something quickly

// Exclude a specific test
testing::GTEST_FLAG(filter) = "-MyLibrary.TestWriting"; // The writing test is broken, so skip it

Puedo comentar ambas líneas para ejecutar todas las pruebas, quitar el comentario de la primera línea para probar una sola característica que estoy investigando/trabajando, o quitar el comentario de la segunda línea si una prueba no funciona pero quiero probar todo lo demás.
También puede probar/excluir un conjunto de características usando comodines y escribiendo una lista, “MyLibrary.TestNetwork*” o “-MyLibrary.TestFileSystem*”.

  • Esta es una gran solución. Lo uso para excluir algunas pruebas por defecto si el filtro está en blanco. Se pueden habilitar con export GTEST_FILTER='*'.

    – Timmmmm

    13 de julio de 2017 a las 14:24

  • En realidad, eso no funciona porque el valor predeterminado es “*” no “”. En su lugar, solo usaré otra variable de entorno que anula el filtro.

    – Timmmmm

    13 de julio de 2017 a las 14:36

  • ¿Dónde definiste el “filtro”? ¿Es una cuerda?

    – sé como uno

    19 de febrero de 2019 a las 21:34

  • No lo defino, así que creo que debe ser un global incluido de gtest/gtest.h?

    – pilkch

    20 de febrero de 2019 a las 12:56

avatar de usuario
vijay c

Si es necesario omitir más de una prueba

--gtest_filter=-TestName.*:TestName.*TestCase

  • Esta es una gran solución. Lo uso para excluir algunas pruebas por defecto si el filtro está en blanco. Se pueden habilitar con export GTEST_FILTER='*'.

    – Timmmmm

    13 de julio de 2017 a las 14:24

  • En realidad, eso no funciona porque el valor predeterminado es “*” no “”. En su lugar, solo usaré otra variable de entorno que anula el filtro.

    – Timmmmm

    13 de julio de 2017 a las 14:36

  • ¿Dónde definiste el “filtro”? ¿Es una cuerda?

    – sé como uno

    19 de febrero de 2019 a las 21:34

  • No lo defino, así que creo que debe ser un global incluido de gtest/gtest.h?

    – pilkch

    20 de febrero de 2019 a las 12:56

avatar de usuario
David C. Obispo

Para otro enfoque, puede envolver sus pruebas en una función y usar comprobaciones condicionales normales en tiempo de ejecución para ejecutarlas solo si lo desea.

#include <gtest/gtest.h>

const bool skip_some_test = true;

bool some_test_was_run = false;

void someTest() {
   EXPECT_TRUE(!skip_some_test);
   some_test_was_run = true;
}

TEST(BasicTest, Sanity) {
   EXPECT_EQ(1, 1);
   if(!skip_some_test) {
      someTest();
      EXPECT_TRUE(some_test_was_run);
   }
}

Esto es útil para mí, ya que estoy tratando de ejecutar algunas pruebas solo cuando un sistema admite IPv6 de doble pila.

Técnicamente, las cosas de dualstack no deberían ser realmente una prueba unitaria, ya que depende del sistema. Pero realmente no puedo hacer ninguna prueba de integración hasta que haya probado que funcionan de todos modos y esto asegura que no informará fallas cuando no sea la falla de los códigos.

En cuanto a la prueba, tengo objetos stub que simulan el soporte de un sistema para dualstack (o la falta de él) mediante la construcción de sockets falsos.

El único inconveniente es que la salida de la prueba y la cantidad de pruebas cambiarán, lo que podría causar problemas con algo que monitorea la cantidad de pruebas exitosas.

También puede usar ASSERT_* en lugar de EQUAL_*. Afirmar voluntad sobre el resto de la prueba si falla. Evita que se descarguen muchas cosas redundantes en la consola.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad