Какая структура проекта предпочтительнее, если присутствуют тесты?

Question

magrif13 апреля 2020 г. 23:28

Какая структура проекта предпочтительнее, если присутствуют тесты?

Добрый день. Решил тут добавить бенчмарков из QtTest в проект и столкнулся с вопросом, а как же всё-таки правильно организовать структуру папок проекта в таком случае. Из активного гугления выделил следующие подходы, основанные на создании подпроектов:
1. Проект делится на подпроекты ( TEMPLATE = subdirs ) по папкам - src где исходный код проекта ну и tests с тестами классов из src . В этом случае классы в тестах подключаются как ../src/MyClass.cpp . При таком подходе, очевидно, необходимо дважды компилировать один и тот же код, что не есть хорошо. Также надо все тестируемые классы добавлять подпроект тестов, и при их обилии тоже не красиво. Тут пример как раз такой реализации (в cmake только).
2. В этой статье товарищ предлагает интересный подход. Идея заключается в том, чтобы разделить проект также на три части - app , lib и test - причем весь проект лежит в lib , а в app один только main.cpp . Тут двойной компиляции не происходит, и проект lib компонуется либо с app , либо с test . Этот подход мне показался довольно интересным.
3. Здесь был предложена интересная идея, которая может базироваться на 1 или 2. Подпроект test поделить ещё на кучу мини-подпроектов, каждый из которых интерактивно даёт возможность внешнему пользователю ознакомиться с интерфейсами того или иного класса.

Какие из этих подходов вы бы [не]использовали? Почему? Какие посоветуете использовать или сами используете?

Рекомендуем хостинг TIMEWEB

Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

Подписка на обсуждение2

Подписка на раздел252

Вам это нравится? Поделитесь в социальных сетях!

14 апреля 2020 г. 13:40
(ред.)

Добрый день.

При использовании TEMPLATE = subdirs не обязательно будет двойная компиляция. subdirs позволяет компилировать проект в несколько библиотек, которые используются несколькими запускаемыми проектами, то есть как вы сказали app и тесты.
По сути все три подхода, что вы описали - это одно и тоже, различаются только уровнем детализации. И во всех подходах будет использоваться организация проекта через subdirs .

Чтобы минимизировать перекомпиляцию нужно проект разделить на библиотеки, которые будут отвечать каждая за свой уровень, то есть, например,

Data
Models
Views
и т.д.

Потом добавить в subdirs проекты самого приложения app, где по сути будет только main.cpp, а также проекты тестов. Тесты лучше разделять на логические небольшие кусочки, как в третьем подходе, чтобы тестировались отдельные части, только изменения одного теста не будет приводить к большой перекомпиляции, а изменение в одной библиотеке не будет приводить к перекомпиляции всех тестов.

m

17 апреля 2020 г. 1:22

А Вы в своих проектах делаете так, что только один main.cpp в app остаётся, а всё остальное в статических библиотеках, или же что-то ещё оставляете в app ? Просто нигде не видел такого, как в 2-м подходе.

Evgenii Legotckoi → magrif
#

17 апреля 2020 г. 14:11
Ответ был помечен как решение.

У нас в app части кроме main.cpp есть ещё несколько файлов, которые очень специфичны для самого app.
У нас подобный подход имеет несколько причин.

Во-первых, всё-таки не так много существует проектов, которым подобное разделение требуется. У большинства проектов нет такого объёма кода, чтобы делить на библиотеки и пытаться оптимизировать сборку. То есть в большинстве случаев достаточно просто иметь нормальный ПК. А у нас в проекте уже на данный момент находится около 100000 файлов.
Во-вторых, подобное разделение на библиотеки позволяет управлять сложностью проекта. Что позволяет унифицировать интерфейсы и классы. В противном случае был бы бардак и изменение кода было бы очень болезненным.
В-третьих, у нас общая кодовая база для четырех программных продуктов и имеется в проекте четыре pro-файла для каждого программного продукта. То есть четыре app, в каждом свои погремушки по мелочи. Как результат, размер самих исполняемых файлов около 15 Мб, а остальные 1,5 Гб - это библиотеки.
Соответственно тесты тоже как отдельные pro проекты, чтобы не мешать всё в общую кучу.

Какая структура проекта предпочтительнее, если присутствуют тесты?

Рекомендуем хостинг TIMEWEB

Комментарии