Организация тестирования единицы/интеграции в решении большой Visual Studio
Начинаю разрабатывать и организовывать тесты для очень большого решения Visual Studio. (Да, я знаю, что тесты должны были разрабатываться вместе с кодом, а не тогда, когда проект близок к завершению, но все так и есть.)
Я видел аналогичные вопросы по организации юнит-тестов в решениях Visual Studio, но не видел ни одного из этих адресно-интеграционных тестов. Хотелось бы получить советы, где разместить тестовые проекты, чтобы они не загромождали и без того большую базу кода.
Вот базовая иерархия вещей в решении. (Все элементы, не заканчивающиеся на .projek, являются папками внутри проекта или Папками решений.)
- HardwareServices
- HardwareService1
- HardwareService1.Core.projek
- HardwareService1.Host.projek
- HardwareService1.Service.projek
- HardwareService2
- HardwareService2.Core.projek
- HardwareService2.Host.projek
- HardwareService2.Service.projek
- HardwareService1
- Инфраструктура
- MyApp.Database.proj
- MyApp.Infrastructure.proj
- MyApp.ReportViewer.proj
- MyApp.SettingsManager.proj
- AppModules
- AppModule1.proj
- Общие
- Отчеты
- Услуги
- ViewModels
- Views
- AppModule2.projek (аналогичная структура с другими модулями AppModules)
- AppModule3.projek (аналогичная структура с другими модулями AppModules)
- AppModule1.proj
- Modules
- ComputeEngine.projek
- Footer.projek
- Header.proj
- CommonServices.proj
Моя идея состояла в том, чтобы сделать папку решения под названием "Tests", а затем имитировать иерархию выше, делая один тестовый проект для каждого проекта производственного кода. В рамках каждого тестового проекта я делал папки под названием "UnitTests" и "IntegrationTests".
Моя задача - создать последовательную схему именования/организации, чтобы не было двусмысленности относительно того, куда должны идти новые тесты и где искать существующие. Учитывая большой размер этого проекта/приложения, я хотел бы получить довольно прочную структуру прямо из ворот, чтобы потом не было больно.
Спасибо за ваше время и совет.