Единичное тестирование. Файловая структура

У меня есть базовая кодовая база С++ с 10-15 приложениями, в которой используется несколько компонентов.

При настройке unittests как для общих компонентов, так и для самих приложений мне было интересно, приняты ли для этого общедоступные файловые структуры.

Поскольку мои модульные тесты имеют несколько базовых классов, чтобы упростить тестовые настройки для проекта/клиента, есть много файлов, которые являются общими для всех тестов.

Мне представляется естественным создать новый каталог, содержащий все связанные с тестированием файлы, mocks и т.д., чтобы все это было централизовано, а также продолжать тестирование связанных определений из основных файлов make.

С другой стороны, я вижу, что обычная практика заключается в том, чтобы тестовые файлы находились вместе с проверенными ими файлами кода.

Есть ли более/менее приемлемый способ сделать это?

Ответы

Ответ 1

С глаз долой, из головы; если вы держите тестовые файлы вместе с файлами кода, разработчикам может быть более очевидным, что при обновлении файла кода они также должны обновить тесты.

Ответ 2

Как вы отметили, существует два распространенных способа поиска файлов unit test: рядом с кодом реализации, который они тестируют, и в отдельной иерархии файлов. Выбор - это вопрос того, что является обычной практикой в ​​вашей организации и личным вкусом.

Что касается места общего тестового кода, просто организуйте свой тестовый код, вы бы организовали код реализации.

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

Ответ 3

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

apps
    app1
        app1module1
        app2module2
        app1tests
    app2
        app2module1
        app2tests
components
    comp1
        comp1module1
        comp1module2
        comp1tests
common_test_stuff

Нет единственного правильного способа сделать это, но это, по-видимому, обычная практика, которая держит производственный и тестовый код раздельными и пытается устранить проблему за пределами видимости, из-за ума (упомянутую zac) в то же время.

Ответ 4

Держите тестовый код рядом с кодом продукта и организуйте свой Makefile (или что-то еще, что вы используете), чтобы тесты собирались одновременно с тестом, чтобы сделать их видимыми, особенно если не все в команде пишет тесты.