Организация модульных и интеграционных тестов в большом решении Visual Studio - PullRequest
5 голосов
/ 08 сентября 2011

Я начинаю разрабатывать и организовывать тесты для очень большого решения Visual Studio.(Да, я знаю, что тесты должны были разрабатываться вместе с кодом, а не тогда, когда проект почти завершен, но все обстоит именно так.)

Я видел похожие вопросы об организации модульных тестов в VisualСтудийные решения, но я не видел ни одного, который бы также касался интеграционных тестов.Я был бы признателен за некоторые рекомендации о том, где разместить тестовые проекты, чтобы они не загромождали и без того большую базу кода.

Вот основная иерархия вещей в решении.(Все элементы, не заканчивающиеся на .proj, являются папками в проекте или папках решений.)

  • HardwareServices
    • HardwareService1
      • HardwareService1.Core.proj
      • HardwareService1.Host.proj
      • HardwareService1.Service.proj
    • HardwareService2
      • HardwareService2.Core.proj
      • HardwareService2.Host.proj
      • HardwareService2.Service.proj
  • Инфраструктура
    • MyApp.Database.proj
    • MyApp.Infrastructure.proj
    • MyApp.ReportViewer.proj
    • MyApp.SettingsManager.proj
  • AppModules
    • AppModule1.proj
      • Общие
      • Отчеты
      • Службы
      • ViewModels
      • Представления
    • AppModule2.proj (структура, аналогичная другим модулям приложений)
    • AppModule3.proj (структура, аналогичная другим модулям приложений)
  • модули
    • вычисленияEngine.proj
    • Footer.proj
    • Header.proj
    • CommonServices.proj

Моя мысль была сделатьПапка решений называется «Тесты» и затем имитирует вышеприведенную иерархию, создавая один тестовый проект для каждого проекта производственного кода.В каждом тестовом проекте я бы создавал папки с именами «UnitTests» и «IntegrationTests».

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

Спасибо за ваше время и советы.

1 Ответ

2 голосов
/ 08 сентября 2011

Соглашение об именах, принятое нашей компанией, заключалось в использовании projectName.Tests.Unit и projectName.Tests.Integration.

С вашей существующей структурой у вас будет что-то вроде этого:

  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
    • Тесты
      • HardwareService1.Core.Tests.Unit
      • HardwareService1.Core.Tests.Integration

Если вы храните папку с тестами вместе с корневой папкой, вам не нужно снова имитировать всю структуру, так как тесты подходят для соответствующего проекта.

примечание

Наличие в имени проекта консистентного Tests.Unit помогает в запуске модульных тестов в сценарии сборки, так как вы можете запускать тесты с помощью поиска по шаблону, например **\*tests.unit*.dll

В конце концов, структура проекта может быть очень субъективной, поэтому делайте то, что имеет смысл в вашей среде и имеет смысл для вашей команды.

...