cmake, C++ тесты в структуре проекта
Ну, например, один из аспектов — это сборка. Мухи отдельно, тесты отдельно.
Типа там в цмаке каком-нибудь
Ну, это как пример. С питоновским размещением ты так рекурсивно не пройдёшь.
Типа там в цмаке каком-нибудь
file(GLOB_RECURSE IO_SOURCES io)
add_library(io_library ${IO_SOURCES})
file(GLOB_RECURSE IO_TESTS tests/io)
add_executable(io_test ${IO_TESTS})
add_test(NAME ...)
Ну, это как пример. С питоновским размещением ты так рекурсивно не пройдёшь.
Все плюсы и минусы - в поддержке проекта и соответствующем изменении cmakelists. Имхо - на вкус.
Вполне можно сделать и так:
-modulezero
--tests
--src
-io
--tests
--src
-core
--tests
--src
храня в корневом cmakelists список папок и собирая сурсы по соответствующим папкам item\src и item\tests
Вполне можно сделать и так:
-modulezero
--tests
--src
-io
--tests
--src
-core
--tests
--src
храня в корневом cmakelists список папок и собирая сурсы по соответствующим папкам item\src и item\tests
Пробовал оба варианта в разное время. Первый действительно из разряда "мухи отдельно, котлеты отдельно", но в итоге это оказалось неудобным, ибо сравнение неуместное.
Сейчас использую второй вариант. Потому что собирать, и уж тем более выкладывать код без прогона тестов занятие бессмысленное, все должно собираться вместе. А по расположению так оказалось удобнее. Все тесты включаются из разных мест в CTest, так что можно все разом прогнать вызовом make test. Правда, я GLOB_RECURSIVE не использую, все исходники прописываю руками.
Единственное неудобство второго подхода - это то, что в Boost.Test, который я использую, нельзя поставить зависимости между модулями. Но на практике тоже оказалось, что не особо нужно. По крайней мере, пока мне так кажется.
Сейчас использую второй вариант. Потому что собирать, и уж тем более выкладывать код без прогона тестов занятие бессмысленное, все должно собираться вместе. А по расположению так оказалось удобнее. Все тесты включаются из разных мест в CTest, так что можно все разом прогнать вызовом make test. Правда, я GLOB_RECURSIVE не использую, все исходники прописываю руками.
Единственное неудобство второго подхода - это то, что в Boost.Test, который я использую, нельзя поставить зависимости между модулями. Но на практике тоже оказалось, что не особо нужно. По крайней мере, пока мне так кажется.
я виндузятник, использую студийные проекты
придерживаюсь второго подхода (если я его правильно понял):
если пишем статическую либу, то _рядом_ делаем юнит-тесты. собственно, в идеале, всегда должна быть пара : либа + тесты для нее
вытаскивать тесты далеко от либы ухудшит поддержку (поменял что-то в либе - поменяй и в тестах; решил удалить либу - удали и тесты и тд) и ориентирование в проекте (а есть ли тесты к либе?)
теперь о зависимостях: если понадобилось линковать либу в свой бинарь, то логично собрать и тесты к этой либе и прогнать их. если не линковал либу, то тесты гонять не надо (казалось бы, очевидно, но следует это зафиксировать явно)
этот подход больше ориентирован на командную разработку и способствует реюзу либ
если же используется первый подход из исходного сообщения ТС, то имхо, это отделение проекта от его тестов и подпапки в tests вообще не обязаны быть как-то связаны с либами, это могут быть логические группы тестов. это более монолитная разработка.
придерживаюсь второго подхода (если я его правильно понял):
если пишем статическую либу, то _рядом_ делаем юнит-тесты. собственно, в идеале, всегда должна быть пара : либа + тесты для нее
вытаскивать тесты далеко от либы ухудшит поддержку (поменял что-то в либе - поменяй и в тестах; решил удалить либу - удали и тесты и тд) и ориентирование в проекте (а есть ли тесты к либе?)
теперь о зависимостях: если понадобилось линковать либу в свой бинарь, то логично собрать и тесты к этой либе и прогнать их. если не линковал либу, то тесты гонять не надо (казалось бы, очевидно, но следует это зафиксировать явно)
этот подход больше ориентирован на командную разработку и способствует реюзу либ
если же используется первый подход из исходного сообщения ТС, то имхо, это отделение проекта от его тестов и подпапки в tests вообще не обязаны быть как-то связаны с либами, это могут быть логические группы тестов. это более монолитная разработка.
(поменял что-то в либе - поменяй и в тестахА это как-то зависит от взаимного расположения?
, нельзя поставить зависимости между модулями.
Это что такое? Если один тест сломался, другие можно не делать?
всем спасибо! Второй вариант мне нравится прежде всего тем, что исходник и пример его использования в одном месте лежат.
Это что такое? Если один тест сломался, другие можно не делать?Да, в Boost.Test есть такая возможность.
Оставить комментарий
Phoenix
В проектах на С++ всегда встречал такую структуру:http://www.opensync.org/browser#trunk/opensync/db
-src
--modulezero
--io
--core
-tests
--modulezero
--io
--core
В python-проектах часто используется
-module
--tests
--submodule
---tests
--submodule2
---tests
Есть какие-то серьёзные причины не делать так на C++ ? вроде как тесты рядом с исходниками удобнее. а если один проект вольётся в другой, то придётся как-то хитро потом переносить все тесты на уровень выше.