Структура каталогов модулей тестирования

Огромные проектные тонны классов и каталогов.

Я делаю проект unit test зеркальным отображением этих каталогов или я помещаю их все в корневой каталог?

Несколько раздражает необходимость изменения каталога и изменения имени класса дважды.

Ответы

Ответ 1

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

Очевидно, вы не используете Java, или ваш тестовый код уже будет иметь ту же структуру пакета, что и тестируемый код, и вопрос будет спорным. (По крайней мере, я не могу представить, чтобы это делалось иначе.)

Ответ 2

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

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