Raggruppamento dei test dell'unità di googletest per categorie

Question

I test dell'unità googletest possono essere raggruppati per categorie? Ad esempio "SlowRunning", "BugRegression", ecc. La cosa più vicina che ho trovato è l'opzione --gtest_filter. Aggiungendo/anteponendo i nomi delle categorie ai nomi dei test o delle fixture posso simulare l'esistenza di gruppi. Questo non mi consente di creare gruppi che normalmente non vengono eseguiti.

Se le categorie non esistono in googletest, esiste una soluzione buona o consigliata?

Modifica: un altro modo è utilizzare i test --gtest_also_run_disabled_. L'aggiunta di DISABLED_ di fronte ai test ti offre esattamente una categoria condizionale, ma mi sembra di abusare di DISABLED quando lo faccio.

Answer 1

Un modo di utilizzare l'opzione gtest_filter e utilizzare la convenzione di denominazione per i test (come descritto in questione).

TEST_F(Foo, SlowRunning_test1) {...} 
TEST_F(Foo, BugRegression_test1) {...} 
TEST_F(Foo, SlowRunningBugRegression_test1) {...} 

In un altro modo utilizzare file binari/eseguibili separati per qualsiasi tipo di test. In questo modo ci sono alcune limitazioni perché gtest usa la autoregistrazione statica, quindi se includi un file sorgente tutti i test implementati in questo file sorgente saranno inclusi nel file binario/eseguibile generato.

Secondo me il primo metodo è migliore. Inoltre, vorrei implementato nuova macro di registrazione di prova per rendere la vita più facile:

#define GROUP_TEST_F(GroupName, TestBase, TestName) \ 
#ifdef NO_GROUP_TESTS \ 
    TEST_F(TestBase, TestName) \ 
#else \ 
    TEST_F(TestBase, GroupName##_##TestName) \ 
#endif 

Answer 2

L'unico modo per eseguire un sottoinsieme di test in un singolo file eseguibile di test è --gtest_filter. Esistono due soluzioni alternative per eseguire test di integrazione e unit test

1. Utilizzare una convenzione di denominazione come Integration.Testname e Unit.Testname. Oltre a ciò, manterrei anche i file di script come RunIntegration.bat e RunUnit.bat da eseguire dagli script di automazione della build per diversi scenari.
2. Mantenere i file eseguibili di test differiti per l'integrazione e l'unità o altre categorie. In studi visivi in ​​avrà progetti separati per ciascuno.