Сборки являются проблемой упаковки / развертывания, поэтому мы обычно разделяем их, потому что не хотим развертывать их с нашим продуктом. Независимо от того, разделили ли вы их по библиотекам или по решениям, у обоих есть свои преимущества.
В конечном счете, вы хотите, чтобы тесты были немедленно доступны всем разработчикам, чтобы разработчики знали, где их найти, когда это необходимо. Вы также хотите создать среду без препятствий с минимальными издержками для написания новых тестов, чтобы вы не вооружали циников, которые не хотят писать тесты. Тесты также должны быстро компилироваться и выполняться - структура проекта может сыграть в этом роль.
Возможно, вы также захотите учесть, что возможны разные уровни тестирования, такие как тесты для юнитов, интеграция или автоматизация пользовательского интерфейса. Разделение этих типов тестов возможно в некоторых инструментах с использованием категорий тестов, но иногда легче выполнять или составлять отчеты, если они являются отдельными библиотеками.
Если у вас есть особые соображения по упаковке, такие как модульное приложение, где модули не должны знать друг о друге, ваши тестовые проекты также должны это отражать.
В небольших проектах, где не так много проектов, соотношение 1: 1 обычно является предпочтительным подходом. Однако производительность Visual Studio быстро снижается по мере увеличения количества проектов. Около 40 проектных отметок становятся препятствием для компиляции и запуска тестов, поэтому более крупные проекты могут выиграть от консолидации тестовых проектов.
Я предпочитаю прагматичный подход, чтобы сложность соответствовала проблеме. Как правило, приложение будет состоять из нескольких слоев, где каждый слой может иметь несколько проектов. Мне нравится начинать с одной тестовой библиотеки на слой, и я имитирую структуру решения, используя папки. Разделитесь, когда сложность оправдывает это. Если вы разрабатываете свои тестовые проекты для гибкости, то переключение обычно безболезненно.