Структура каталогов поблочного тестирования
Огромные тонны проекта классов и каталогов.
Я заставляю свой проект модульного теста зеркально отразить эти каталоги, или я помещаю их всех в корневой каталог?
Несколько раздражающий для внесения изменений каталога и имени класса изменяется дважды.
2 ответа
Вы определенно хотите, чтобы каталоги ваших юнит-тестов отражали каталоги тестируемого кода. Это легкая боль при настройке вручную, но эта боль не длится так долго, как боль от того, что все ваши тесты собраны в кучу или, что еще хуже, находятся в какой-то иной структуре, чем тестируемый код.
Очевидно, вы не используете Java, иначе ваш тестовый код уже имел бы ту же структуру пакетов, что и тестируемый код, и вопрос был бы спорным. (По крайней мере, я не могу представить себе, как это можно сделать по-другому)
.Я бы предпочел, чтобы юнит-тесты находились в директории проекта, чтобы они были физически близки к коду, который они поддерживают. Каталог, содержащий модульные тесты для одного компонента/пакета, находится в каталоге этого компонента/пакета, в определенном каталоге test, на одном уровне с каталогом src. Это то, что я делаю для проектов на C/C++, FWIW. Основная причина заключается в том, чтобы иметь возможность компилировать компонент и его модульные тесты одновременно, чтобы сделать модульные тесты видимыми (наши старые компоненты не все имеют модульные тесты).
Таким образом, каждое изменение в структуре каталогов не влияет на структуру каталогов тестов, поскольку модульные тесты переносятся вместе с рабочим кодом. Наличие двух параллельных структур каталогов, на мой взгляд, является дублированием.