Лучше ли иметь проект по единичному тестированию на решение или проект единичного тестирования для каждого проекта?
В каждом решении, если у вас есть 5 проектов в решении, вы получаете 1 проект с единичным тестированием, содержащий тесты для каждого из 5 проектов.
Для каждого проекта, если у вас есть 5 проектов в решении, вы получаете 5 проектов с единичным тестированием.
Каков правильный путь?
Я думаю, что это не тот же вопрос, что и Write Unit тесты в сборку или в отдельной сборке?
Ассембли являются проблемой упаковки/развертывания, поэтому мы обычно их разделяем, потому что мы не хотим размещать их с нашим продуктом. Независимо от того, разделите ли вы их на одну библиотеку или на одно решение, есть достоинства для обоих.
В конечном счете, вы хотите, чтобы тесты были немедленно доступны всем разработчикам, чтобы разработчики знали, где их найти, когда это необходимо. Вы также хотите создать среду с препятствиями с минимальными накладными расходами для написания новых тестов, чтобы вы не вооружали циников, которые не хотят писать тесты. Тесты также должны быстро компилироваться и выполняться - структура проекта может играть определенную роль во всем этом.
Вы также можете подумать о том, что возможны различные уровни тестирования, такие как тесты на единицу, интеграцию или автоматизацию пользовательского интерфейса. Разделение этих типов тестов возможно в некоторых инструментах с использованием категорий тестов, но иногда это проще для выполнения или отчетности, если они являются отдельными библиотеками.
Если у вас есть особые соображения по упаковке, такие как модульное приложение, в котором модули не должны знать друг о друге, ваши тестовые проекты также должны отражать это.
В небольших проектах, где проектов не так много, соотношение 1:1 обычно является предпочтительным. Однако производительность Visual Studio быстро ухудшается по мере увеличения количества проектов. Около 40 компиляции метки проекта становятся препятствием для компиляции и запуска тестов, поэтому более крупные проекты могут выиграть от консолидации тестовых проектов.
Я предпочитаю прагматичный подход, чтобы сложность соответствовала этой проблеме. Как правило, приложение будет состоять из нескольких слоев, где каждый уровень может иметь несколько проектов. Мне нравится начинать с одной тестовой библиотеки на каждый слой, и я имитирую структуру решения, используя папки. Разделите, когда это требует. Если вы разрабатываете свои тестовые проекты для гибкости, то переход обычно безболезнен.
Я бы назвал отдельный проект для каждого проекта unit test, а не в одном проекте для каждого решения. Я думаю, что это лучше, потому что это сэкономит вам много хлопот, если вы решите вывести конкретный проект из решения и переместить его в другое решение.
Мы имеем отношение один к одному от файла к проектам решения в очень большой системе, мы достигли точки, когда сборка занимает более 90 минут каждый раз, когда мы регистрируемся. Я создал новую конфигурацию решения, которая строит только тестовые проекты, новые настройки запускаются один раз в сутки, чтобы убедиться, что все тестовые примеры работают, разработчики могут переключиться на unittest config, чтобы проверить свой код в своей среде разработки. Pl. дайте мне знать ваш канал назад
Лично я пишу одну тестовую сборку для каждого проекта. Затем я создаю один проект nunit для каждого решения и ссылаюсь на все соответствующие тестовые сборки. Это отражает организацию проектов и означает, что, если проекты повторно используются в разных решениях, тогда необходимо выполнить только соответствующие модульные тесты.
Я собираюсь с одним из ответов "это зависит". Лично я, как правило, ставил все тесты в одном проекте с отдельными папками в проекте для каждой сборки (плюс дополнительные подпапки по мере необходимости). Это позволяет легко запускать весь набор, либо из VisualStudio, либо с помощью CruiseControl.net.
Если у вас тысячи тестов, один проект может оказаться слишком сложным для поддержания. Кроме того, как отметил Питер Келли в своем ответе, возможность легко разбить тесты, если вы переместите проект, может быть полезна.