Подробное руководство по настраиваемому решению для тестирования интеграции с использованием xUnit и Docker в Azure Pipelines.

Функциональные сквозные тесты - одна из самых важных вещей, которые вы можете иметь для своего приложения. Но выполнение сквозных тестов не так просто, как создание модульных тестов, потому что это может быть объединение модульных тестов и интеграционных тестов. Вам нужно будет развернуть среду тестирования и, что более важно, все это нужно будет сделать в конвейере CI.

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

Что такое сквозное тестирование?

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

Но в этой статье я покажу вам, как проводить сквозное тестирование ваших API-интерфейсов с помощью конвейеров xUnit и Azure. Вы узнаете, как создать фиктивную базу данных с помощью Docker и как имитировать свои интерфейсы с помощью NSubstitute и AutoFixture.

Написание модульных тестов с использованием xUnit

Перед тем как начать, я должен сообщить вам, что в этом разделе я буду использовать четыре основных пакета для модульного тестирования:

  • xUnit
  • NSubstitute
  • Автофиксация
  • FluentAssertions

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

Например, вы хотите создать набор для тестирования, который проверяет, возвращает ли метод список ролей пользователей, если он предоставлен с пустыми параметрами. Перед тем, как инициировать тест, вам необходимо создать испытуемого (SUT) с соответствующей зависимостью.

Обработчиком будет SUT, а репозиторий будет имитировать с помощью NSubstitute, наконец, нам нужно запустить экземпляр IFixture, чтобы помочь сгенерировать поддельные данные.

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

После того, как вы создали поддельные результаты, вам необходимо выполнить метод.

Чтобы проверить результаты, вы можете использовать беглые методы утверждения. Свободное утверждение - это не функция по умолчанию, предоставляемая стандартными наборами тестирования Microsoft, это настраиваемый пакет, который вы можете установить. Если у вас есть метод, который не обнаруживает ошибок, попробуйте сначала установить пакет FluentAssertions.

Создание автономной базы данных с помощью Docker

Прежде чем вы начнете писать сквозные тесты с использованием xUnit, вам нужно будет подключиться к тестовой базе данных. Самый простой способ создать тестовую базу данных - использовать Docker. Используя Docker, вы можете создать образ своей базы данных, заполненный данными тестирования. Лучше всего то, что вы можете интегрировать его со своим конвейером CI для создания функциональных тестов.

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

Затем создайте Dockerfile, который будет строить ваш собственный образ, предполагая, что вы будете использовать SQL Server, следующие Dockerfile будут использовать SQL Server, как показано ниже:

Написание интеграционных тестов с использованием xUnit

Написать интеграционные тесты довольно просто, но перед тем, как начать, я должен сообщить вам, что в этом разделе я буду использовать два основных пакета для интеграционного тестирования:

  • xUnit
  • Microsoft.AspNetCore.Mvc.Testing

Для этого требуется Microsoft.AspNetCore.Mvc.Testing пакет, поставляемый Microsoft. Этот пакет предоставляет все необходимое для тестирования API в памяти. Предполагая, что ваша база данных уже работает в фоновом режиме, все, что вам нужно, это создать тесты.

Например, давайте проведем тест, который проверит, возвращает ли конечная точка /users код состояния успеха.

Каждый тестовый класс расширяет интерфейс IClassFixture. IClassFixture предоставляется с использованием класса WebApplicationFactory. WebApplicationFactory будет использоваться для создания клиента в памяти, который будет очень похож на производственный. Вам нужно будет только выполнить GET методы на /users конечной точке, после чего вы сможете получить и подтвердить код состояния.

Поскольку ответ будет обычным ответом HTTP-клиента в .NET, вы можете подтвердить код состояния, используя:

await client.GetAsync(url);

Кроме того, вы можете получить доступ к содержимому ответа, используя:

await response.Content.ReadAsStringAsync();

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

Автоматизация тестов внутри сборки CI с помощью Azure Pipeline

В целях безопасности Azure Pipelines требует, чтобы вы разместили частный агент сборки для запуска образа Linux Docker внутри вашего конвейера CI. А чтобы запускать тесты XUnit, вам нужно запускать их на машине, на которой установлена ​​Visual Studio.

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

Установка агента сборки Visual Studio

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

Сначала перейдите в настройки проекта:

Затем перейдите в раздел Пулы агентов и щелкните свой пул агентов по умолчанию.

Нажмите Новый агент.

Затем появится всплывающее окно, и вам нужно будет:

  1. Откройте вкладку Windows.
  2. Скопируйте URL-адрес загрузки агента.

TL; DR Чтобы помочь вам быстрее пройти через все это, вы можете скачать агент здесь (ссылка указывает на версию агента 2.193.1) и обновить его позже.

Затем перейдите в свой каталог C: и введите команду create a new directory agent:

mkdir agent
cd agent

Затем создайте агент, распаковав загруженный пакет:

Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory(“$HOME\Downloads\vsts-agent-win-x64–2.193.1.zip”, “$PWD”)

Затем настройте агент, запустив сценарий настройки:

.\config.cmd

Наконец, запустите агент с помощью сценария run.cmd:

.\run.cmd

Чтобы включить Visual Studio в вашем агенте Windows, вам нужно всего лишь загрузить и установить Visual Studio на свой компьютер. Поскольку в моем примере будет использоваться VS2017, вы можете получить URL-адрес загрузки для VS2017 здесь.

Создание конвейера CI

Сначала создайте новый конвейер CI:

  1. Перейдите в каталог вашего конвейера.
  2. Нажмите Создать конвейеры.

При попытке создать шаблон CI включите классический редактор.

Далее определите, над каким проектом вы будете работать:

  1. Выберите Проект.
  2. Выберите назначенный репозиторий.
  3. Выберите ветку, которая запустит сборку CI.
  4. Когда все будет готово, еще раз проверьте и нажмите Продолжить.

Чтобы упростить создание нового шаблона:

  1. Найдите предопределенный шаблон ASP.NET Core.
  2. Примените шаблон.

Затем используйте установленный вами агент Visual Studio:

  1. Откройте вкладку Конвейер.
  2. Щелкните раскрывающийся список "Пул агентов".
  3. Выберите собственный пул агентов.

В этом конкретном решении ASP.NET Core я разделил его на три проекта, в основном проекты Application, UnitTest и IntegrationTest. Этапы восстановления и строительства также будут разделены для трех проектов.

В настоящее время вы собираетесь настроить восстановление для проекта Application:

  1. Щелкните задачу восстановления.
  2. Разорвите связь с проектом, щелкнув символ цепочки.
  3. Затем нажмите Отменить связь.

Затем измените Путь к проектам на файл проекта вашего приложения.

Затем проделайте то же самое с задачей Build:

  1. Щелкните задачу сборки.
  2. Измените путь к проекту на файл проекта приложения.
  3. Добавьте конфигурацию, чтобы сборка не восстанавливала зависимости (потому что это было сделано с помощью предыдущей задачи).

Очистите неиспользуемые задачи:

  1. Щелкнув по задаче, которую хотите удалить.
  2. Нажав кнопку Удалить.

Поскольку в моем примере потребуется appsettings.json:

  1. Нажмите кнопку +.
  2. Поскольку вы работаете в ОС Windows, выберите для поиска Powershell.
  3. Нажмите Добавить.

Задача Powershell будет использоваться для вставки appsettings.json в папку проекта приложения с помощью сценария Powershell.

Чтобы вставить скрипт Powershell:

  1. Щелкните задачу Powershell.
  2. Измените отображаемый заголовок задачи на Копировать appsettings.json.
  3. Измените тип скрипта на встроенный.
  4. Добавьте скрипт.

Затем вам нужно будет восстановить и построить проекты модульных тестов, вы можете легко сделать это, клонировав две предыдущие задачи для проекта Application:

  1. Щелкните левой кнопкой мыши задачу восстановления проекта.
  2. Выберите вариант Клонировать задачу.

После клонирования задачи восстановления:

  1. Щелкните по клонированной задаче.
  2. Измените отображаемое имя.
  3. Измените расположение файла проекта.

Затем повторите шаг для задачи сборки, а затем:

  1. Щелкните по клонированной задаче.
  2. Измените отображаемое имя.
  3. Измените расположение файла проекта.
  4. Проверьте конфигурацию, чтобы предотвратить восстановление во время сборки, добавьте ее, если она не существует.
  5. Сделайте это еще раз для проекта тестирования интеграции.

Чтобы запустить базу данных Docker, вам необходимо добавить задачу Docker:

  1. Нажмите кнопку +.
  2. Найдите задачу Docker.
  3. Нажмите Добавить.

Прежде чем вы сможете запустить свой контейнер Docker, вам нужно сначала его собрать:

  1. Щелкните новую задачу Docker.
  2. Измените версию задачи на 0. *.
  3. Измените действие на Создание изображения.
  4. Обновите тип реестра контейнеров, чтобы использовать обычный реестр контейнеров.
  5. Вставьте местоположение вашего Dockerfile.

Добавьте еще одну задачу Docker для запуска образа:

  1. Щелкните новую задачу Docker.
  2. Измените версию задачи на 0. *.
  3. Измените действие на Запуск изображения.
  4. Снимите флажок Укажите название изображения.

Добавьте тестовую задачу Visual Studio:

  1. Нажмите кнопку +.
  2. Найдите задачу Visual Studio Test.
  3. Нажмите Добавить.

Настройте тестовую задачу Visual Studio:

  1. Щелкните задачу.
  2. Измените отображаемое имя.
  3. Определите тестовые файлы.

Сценарий тестового файла выглядит следующим образом:

**\bin\$(BuildConfiguration)\**\*test*.dll
!**\obj\**
!**\xunit.runner.visualstudio.testadapter.dll
!**\xunit.runner.visualstudio.dotnetcore.testadapter.dll

Добавьте еще одну задачу для публикации теста:

  1. Нажмите кнопку +.
  2. Найдите задачу «Опубликовать результаты теста».
  3. Нажмите Добавить.

Наконец, настройте задачу публикации результатов теста:

  1. Щелкните задачу.
  2. Измените отображаемое имя.
  3. Измените ожидаемый формат теста на XUnit.

TL; DR Если по какой-либо причине классический редактор устареет, вы можете скопировать YAML-версию конвейера здесь:

Заключение

В этом руководстве вы узнали, как создать базовый сквозной тест с помощью XUnit и как запустить его в конвейере непрерывной интеграции с помощью Azure Pipelines. Цель сквозных тестов - убедиться, что ваше приложение работает безупречно, в данном случае, чтобы убедиться, что ваши API безупречны.

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