Как проверить пакеты развертывания, созданные msbuild? (желательно с помощью mstest или nunit)

Question

Наш процесс msbuild создает множество zip-пакетов для развертывания (в основном веб-сайтов, но также и других). У нас есть множество повторяющихся проблем, которые продолжают красться - включенные файлы, которых не должно быть, недостающие ресурсы. Это крики для автоматической проверки. Критерии для проверки просты

Проверка пакета foosite:

• Файлы ресурсов присутствуют.
• Нет файлов результатов теста, файлов obj или других артефактов сборки
• И так далее.

В идеале я мог бы использовать nunit или mstest, с которыми когда-либо был знаком каждый. Msbuild знает, где находятся пакеты. У нас много пакетов, возможна одновременная сборка в разных ветках. Следовательно, расположение пакетов и имена пакетов не являются детерминированными - поэтому тесты не знают, где находятся пакеты.

Какой самый простой способ передачи информации о msbuild в mstest или nunit? Ответ на этот вопрос мог бы дать один из возможных ответов, однако, этот вопрос получил архитектурный совет вместо ответа , Я знаю, что это не модульный тест, но тестовая среда удобна, в любом случае. Я мог бы создать exe для проверки сборки - но зачем добавлять пару часов в проект?

Или, у вас есть лучшее предложение для автоматической проверки пакетов сборки? (MSI, zips, что угодно)?

Answer 1

То, что я в итоге сделал, - это набор пользовательских задач сборки MS, которые раскручивают виртуальную машину на Virtual Server, копируют MSI на машину, бесшумно разворачивают ее и затем проверяют на соответствие. Я использовал PSExec для запуска MSI. Затем он мог бы использовать бегунок командной строки MSTest , чтобы использовать MSTest и запустить ваши тестовые биты.

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

Answer 2

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

Вы могли бы даже использовать некоторые методы TDD против пакетов. Например, если у вас произошел сбой развертывания из-за отсутствия определенного файла, напишите модульный тест, который не пройден из-за отсутствия файла; изменить сборку так, чтобы файл присутствовал; затем убедитесь, что модульный тест прошел успешно.

Но в целом проблемы развертывания шире, и я повторяю предложение blowdart . Развертывание на одной или нескольких виртуальных машинах, а затем автоматическое тестирование в развернутых средах. Эти тесты будут проверять не только простые вещи, например, была ли ошибка, возвращенная во время самой установки; они также проверяли бы, как правильно настроены виртуальные каталоги IIS с правильными свойствами и содержимым, и работает ли веб-сайт в основном.

Я бы использовал несколько разных виртуальных машин для тестирования различных сценариев развертывания: один для чистого развертывания; один для обновления с версии.-1 и т. д. Возможно, что для каждой среды могут быть проведены одинаковые или похожие тесты IVT.

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