CMake + Boost test: игнорировать тесты, которые не могут быть построены

Question

У нас есть проект на C++, который имеет относительно большое количество наборов тестов, реализованных в Boost/Test. Все тесты хранятся вне основного дерева проекта, каждый набор тестов находится в отдельном файле .cpp. Таким образом, наша текущая CMakeLists.txt для тестов выглядит следующим образом:

cmake_minimum_required(VERSION 2.6) 

project(TEST_PROJECT) 
find_package(Boost COMPONENTS unit_test_framework REQUIRED) 

set(SPEC_SOURCES 
    main.cpp 
    spec_foo.cpp 
    spec_bar.cpp 
    ... 
) 

set(MAIN_PATH some/path/to/our/main/tree)  
set(MAIN_SOURCES 
    ${MAIN_PATH}/foo.cpp 
    ${MAIN_PATH}/bar.cpp 
    ... 
) 

add_executable (test_project 
    ${SPEC_SOURCES} 
    ${MAIN_SOURCES} 
) 

target_link_libraries(test_project 
    ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY} 
) 

add_test(test_project test_project) 

enable_testing() 

Он работает нормально, но проблема SPEC_SOURCES и MAIN_SOURCES довольно длинные списки и кто-то изредка прорывается что-то в любом из файлов в главном дереве или источников. Это, в свою очередь, делает невозможным создание целевого исполняемого файла и тестирование остальных. Нужно вручную выяснить, что было сломано, перейдите в CMakeLists.txt и закомментируйте части, которые не могут скомпилироваться.

Итак, вопрос: есть ли способ игнорировать тесты, которые не в состоянии автоматически строить в CMake, обобщать, ссылку и запустить остальные (в идеале, разметить те, которые не удалось, как «не удалось построить»)?

Удаленный вопрос Best practice using boost test and tests that should not compile предлагает команду try_compile в CMake. Однако в своей голой форме он просто запускает новый созданный CMakeList (который будет работать не так, как оригинальный), и не имеет никаких крючков для удаления несовместимых единиц.

Answer 1

Я думаю, вы можете создать один тестовый исполняемый файл для каждого источника спецификации, (с помощью foreach() loop), а затем сделать что-то вроде:

make spec_foo && ./spec_foo 

Это будет только попытаться построить бинарное соответствие тест, который вы хотите запустить

Но если ваш билд часто не может быть признаком какого-то плохого дизайна в вашем производстве код ...

Answer 2

Я думаю, что у вас есть некоторые проблемы в вашем подхода к тестированию.

Надо вручную выяснить, что было нарушено, перейти в CMakeLists.txt и закомментировать части, которые не компилировать.

Если у вас есть хороший охват с помощью модульных тестов, вы должны иметь возможность быстро выявлять и находить проблемы. Непрерывная интеграция (например, Jenkins, Buildbot, Travis (GitHub)) может быть очень полезной. Они будут запускать ваши тесты, даже если некоторые разработчики не сделали этого до совершения.

Также вы предполагаете, что некомпилирующий класс (и его тест) просто должен быть удален из сборки. Но как насчет транзитивных зависимостей, когда не компилируемый класс нарушает компиляцию других классов или приводит к связыванию ошибок. Что относительно тестов, которые нарушают сборку? Все это происходит во время развития.

Я предлагаю вам разделить свою сборку на множество библиотек, каждая из которых имеет свой собственный тестовый бегун. Составьте вместе то, что принадлежит вместе (сплоченность). Попробуйте также минимизировать зависимости в вашей компиляции (инъекция зависимостей, интерфейсы, ...). Это позволит сохранить процесс разработки, собрав библиотеки и протестировать бегуны, даже если некоторые библиотеки не компилируются (в течение некоторого времени).