Тестирование пакета NuGet

Question

Мы большие пользователи NuGet, у нас есть 25-30 пакетов, которые мы делаем доступными на общем сетевом ресурсе.

Мы хотели бы иметь возможность протестировать новые пакеты перед их сборкой и выпуском в приложениях-потребителях.В идеале это можно сделать, используя что-то похожее на снимок Maven и имея специальный пакет разработки (например, функциональность снимка ).

Кто-нибудь еще придумал, в идеале разумно не хакерский, способ сделать это?

Наш предпочтительный метод - генерировать сборки пакетов, а затем вручную перезаписывать сборки в каталоге packages /, т. Е. Заменять фактические ссылки на проекты, но это не кажется особенно чистым.

Обновление:

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

Answer 1

Я закончил тем, что написал инфраструктуру тестирования модулей / интеграций для решения проблемы симуляции.По сути, мне нужно было проверить содержимое пакета, версии и информацию, что произойдет, когда я установил и удалил пакет, какие версии были сборками в lib, какими битами были собраны сборки (x86 или x64) ии так далее - и мне нужно было, чтобы все это работало без установленной Visual Studio и на моей сборочной машине (без головы) в качестве качественных ворот.

Стоя на плечах таких гигантов, как: Пестер , PETools и Модуль управления пакетами SharpDevelop Я собрал - nuget-test

1. Клонировать проект в каталог вашего пакета(где ваш файл .nuspec и файлы пакета).Если по какой-либо причине вы хотите сохранить проект nuget-test как репозиторий «git», просто удалите команду «remove-item nuget-test / .git -Recurse -Force» из приведенной ниже команды.

   git clone https://github.com/nickfloyd/nuget-test.git; remove-item nuget-test/.git -Recurse -Force

2. Запустите файл Setup.ps1 в корне каталога nuget-test в x86 экземпляре PowerShell .

   PS> .\setup.ps1

3. Напишите тесты и поместите их в каталог nuget-test / test, используя синтаксис Pester .

4. Выполнить тесты.

   PS> Invoke-Pester

Страница проекта: nuget-test
На github: https://github.com/nickfloyd/nuget-test

Надеюсь, это поможет вам приблизиться к тому, что вы пытаетесь сделать.

Answer 2

Если вы используете пакеты NuGet для распространения ваших библиотек, вам не следует ограничиваться только тестированием библиотек. Вам также следует протестировать сами пакеты (если ваши двоичные файлы исправны, но неправильно установлены, у потребителей все еще есть проблемы). Все дело в том, чтобы улучшить этот опыт.

Одним из способов может быть дополнительный репозиторий CI или QA . То, что у вас есть, на самом деле является вашим «производственным» хранилищем, содержащим расходные релизы, которые считаются готовыми высококачественными продуктами.

Если пойти дальше, у вас может быть логический процесс продвижения пакета (на основе непрерывной интеграции или даже с использованием подхода непрерывной доставки), где: - каждая регистрация создает пакет в вашем репозитории CI - тестировщики выбирают пакет CI для QA и, если найден ОК, продвигают его либо в канал QA, либо в канал Production (все, что вы предпочитаете, зависит от качества вашего тестирования и от того, насколько хорошо оно автоматизировано)

Существуют различные способы реализации этого сценария, используя простые сетевые ресурсы, внутренние реализации NuGet.Server или Gallery, или просто используйте http://myget.org, чтобы попробовать его с минимальными затратами и нулевыми усилиями.

Надеюсь, это поможет!

Ура, Xavier