Группировка модульных тестов googletest по категориям

Можно ли группировать модульные тесты googletest по категориям? Например, «SlowRunning», «BugRegression» и т. д. Самое близкое, что я нашел, — это параметр --gtest_filter. Добавляя/добавляя имена категорий к именам тестов или приборов, я могу имитировать существование групп. Это не позволяет мне создавать группы, которые обычно не запускаются.

Если категории не существуют в googletest, есть ли хороший или лучший обходной путь?

Изменить: Другой способ — использовать файл --gtest_also_run_disabled_tests. Добавление DISABLED_ перед тестами дает ровно одну условную категорию, но мне кажется, что я неправильно использую DISABLED, когда делаю это.


person walrii    schedule 26.09.2012    source источник


Ответы (2)


Один из способов использовать параметр gtest_filter и использовать соглашение об именах для тестов (как вы описываете в вопросе).

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

В противном случае используйте отдельные двоичные файлы/исполняемые файлы для любого типа теста. Этот способ имеет некоторые ограничения, потому что gtest использует статическую авторегистрацию, поэтому, если вы включите какой-либо исходный файл, все тесты, реализованные в этом исходном файле, будут включены в сгенерированный двоичный/исполняемый файл.

На мой взгляд первый способ лучше. Кроме того, я бы реализовал новый макрос тестовой регистрации, чтобы облегчить себе жизнь:

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

Единственный способ запустить подмножество тестов в одном исполняемом файле теста — это --gtest_filter. Существует два обходных пути для выполнения, скажем, интеграционных тестов и модульных тестов.

  1. Используйте соглашение об именах, например Integration.Testname и Unit.Testname. В дополнение к этому я также буду поддерживать файлы сценариев, такие как RunIntegration.bat и RunUnit.bat, для запуска из моих сценариев автоматизации сборки для различных сценариев.
  2. Сохраняйте разные тестовые исполняемые файлы для интеграции и модулей или других категорий. В визуальных студиях у каждого будут отдельные проекты.
person NiladriBose    schedule 26.09.2012
comment
Мне нравится идея отдельных исполняемых файлов, но это будет означать либо разделение категорий на отдельные исходные файлы, либо использование #define и повторное создание файлов .o. Ни то, ни другое не очень вкусно. - person walrii; 02.10.2012
comment
Я, наверное, не понимаю вашего комментария. Почему вы считаете, что разделение на отдельные тестовые файлы - плохая идея. По мере роста вашего тестового набора будет выгодно модульность теста, создание глубоких пространств имен и т. д. Если вас беспокоит повторное использование/дублирование кода, вы можете начать использовать общую тестовую оснастку между типами тестов code.google.com/p/googletest/wiki/ - person NiladriBose; 02.10.2012
comment
Я определенно верю в разделение тестов на отдельные файлы. Но если у меня есть файл с тестами для X, мне не нравится выделять один тест в отдельный файл только потому, что он относится к категории долгоиграющих. Использование отдельных исполняемых файлов для категорий потребует этого или перекомпиляции одного и того же файла с другими #define. - person walrii; 02.10.2012
comment
Хорошо, вы узнали о перекомпиляции, что означало бы дополнительный шаг сборки. Возможно, вы уже пробовали это вместо использования #define для параметризации, я бы посмотрел на code.google.com/p/googletest/wiki/ , чтобы не переписывать тесты , чтобы один и тот же тест можно было использовать для длительного или короткого выполнения в зависимости от параметра. - person NiladriBose; 03.10.2012
comment
Я использую параметризованные тесты значений и типов. Но разные категории — это не просто разные параметры других тестов. - person walrii; 04.10.2012