Изначально эта история была опубликована в моем блоге на KrissTech.
Когда дело доходит до тестирования ваших проектов, важно не только избежать ошибок при разработке новых функций, но и избежать регресса в других, казалось бы, несвязанных компонентах. Не все проводят непрерывные модульные тесты всего решения во время локальной разработки, поэтому вдвойне важно протестировать все, прежде чем фактически интегрировать какие-либо изменения в мастер (или как вы решите это назвать).
Хотя есть много способов сделать это для всех популярных систем управления версиями исходного кода, в этой статье я буду исследовать конвейеры Azure DevOps и репозитории Azure GIT, поскольку это то, с чем я экспериментировал в последнее время.
Создание проекта
Прежде чем мы сможем исследовать Azure, нам нужно что-то там разместить, что можно будет протестировать. Я создам простое клиент-серверное приложение, которое использует Angular на стороне клиента с .Net Core WebApi на бэкэнде (снова , поскольку это технологии, с которыми я играл в последнее время, вы можете заменить свой собственный стек).
Угловой
Во-первых, давайте создадим приложение Angular. Если вы еще не сделали этого, установите NodeJS и запустите
npm install -g @angular/cli
чтобы убедиться, что у вас установлена последняя версия Angular. На момент написания этой версии это Angular 7.
Теперь, чтобы запустить приложение,
ng new azure-app
Выберите любые параметры, которые вам нравятся, и позвольте ему установить. Это уже должно быть настроено с парой модульных тестов для наших демонстрационных целей, и это здорово! Есть еще пара вещей, которые нужно настроить.
Во-первых, мы должны настроить репортер тестов и набор тестов CI для модульных тестов Karma. Добавьте в проект зависимость разработки karma-junit-test.
yarn add -D karma-junit-test
Теперь добавьте плагин в файл конфигурации karma.conf.js.
require('karma-junit-reporter'),
И обновите файл Package.json с помощью дополнительной команды.
"test:ci": "ng test --watch=false --browsers=ChromeHeadless --reporters=progress,junit",
Это запустит тесты один раз, без режима просмотра, а также сгенерирует файл результатов теста, который мы сможем использовать позже.
Для сквозных тестов процедура в чем-то похожа. Во-первых, добавьте репортера в набор для тестирования жасмина.
yarn add -D jasmine-reporters
Затем откройте файл protractor.conf.js, импортируйте тестовый репортер и добавьте аргумент в браузер Chrome для использования безголового режима.
const { JUnitXmlReporter } = require('jasmine-reporters'); ... capabilities: { chromeOptions: { args: [ "--headless" ] }, 'browserName': 'chrome' },
В том же файле в разделе onPrepare () добавьте еще один репортер для тестов жасмина.
jasmine.getEnv().addReporter( new JUnitXmlReporter({ consolidateAll: true, savePath: 'e2e', filePrefix: 'TESTS-E2E' }) );
Это должно быть все для настройки тестирования на стороне клиента.
.NET Core
Далее нам понадобится какой-нибудь сервер. Убедитесь, что dotnet установлен. Теперь давайте запустим пару команд
dotnet new webapi -o AzureApp.Api dotnet new xunit -o AzureApp.Api.Tests
Теперь, прежде чем мы продолжим, давайте переставим три папки, которые мы создали, во что-то более разумное. Создайте новую папку для хранения и клиента, и сервера (я назвал свой AzureTest) и переместите в нее три папки, созданные ранее. Переименуйте папку azure-app в client. Создайте папку с именем server и переместите в нее два проекта dotnet.
Поскольку в angular уже есть некоторые тесты, мы не будем создавать дополнительные тесты для этой демонстрации. Что касается точки зрения dotnet, давайте зайдем в папку tests и добавим правильные ссылки:
cd server/AzureApp.Api.Tests/
dotnet add reference ../AzureApp.Api/AzureMedium.Api.csproj
cd server/AzureApp.Api.Tests/
dotnet add reference ../AzureApp.Api/AzureMedium.Api.csproj
Теперь мы можем добавить модульный тест, чтобы получить значения от нашего контроллера API и убедиться, что они соответствуют нашим ожиданиям. Для простоты откройте существующий файл UnitTests1.cs и замените его следующим кодом:
using System; using Xunit; using AzureApp.Api.Controllers; namespace AzureApp.Api.Tests { public class UnitTest1 { [Fact] public void ValuesController_GetAll_ReturnsCorrectData() { var controller = new ValuesController(); var result = controller.Get(); Assert.Equal(new string[] { "value1", "value2" }, result.Value); } } }
Если у вас возникли проблемы, вам может потребоваться указать версию в AzureApp.Api.csproj.
<!-- Make sure to specify the version that you are using --> <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.0"/>
Лазурь
Теперь у нас есть три разных набора тестов, которые запускаются с использованием трех разных команд - модульных тестов Angular, тестов Angular E2E и модульных тестов .NET Core.
Предложение Azure DevOps включает удобные конвейеры для настройки всего процесса сборки CI / CD. Конвейеры можно настроить с помощью графического интерфейса или файла YAML. В этой статье я сосредоточусь на настройке файла YAML.
Настройка YAML
Сначала в корневом каталоге создайте файл с именем azure-pipelines.yml
(на самом деле он может называться как угодно). Затем вы можете добавить в файл следующее содержимое.
pool:
vmImage: 'Ubuntu 16.04'
trigger:
- master
variables:
buildConfiguration: 'Release'
steps:
- script: cd ./server/AzureApp.Api/ && dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build'
- task: DotNetCoreCLI@2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: NodeTool@0
inputs:
versionSpec: '10.x'
- script: cd client/ && npm install
displayName: 'npm install'
- script: cd client/ && npm build
displayName: 'Build Angular App'
- script: cd client/ && npm run test:ci
displayName: 'Angular Karma unit tests'
- script: cd client/ && npm run e2e
displayName: 'Angular Protractor E2E tests'
- task: PublishTestResults@2
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/TESTS-*.xml'
Этот файл YAML определяет несколько этапов сборки и где их запускать.
Во-первых, в разделе pool указывается, на какой виртуальной машине запускать тесты. Их можно найти в документации Azure DevOps. В разделе trigger указывается, на какой ветви или триггере (только запросы на вытягивание или что-то еще) будет выполняться сборка. шаги - это то, что определяет фактические действия конвейера. Если какой-либо из них не удастся, сборка завершится неудачно, а остальные шаги не будут выполнены.
Первый шаг - создать проект .NET, а затем протестировать его с помощью инструмента, доступного в Azure DevOps. Инструменты в основном представляют собой оболочки команд интерфейса командной строки (dotnet test и т. Д.)
Затем мы настраиваем узел, устанавливаем зависимости, собираем приложение и запускаем оба набора тестов Angular.
Последний шаг - опубликовать результаты теста в Azure.
Настройка сборки
Теперь, когда файл YAML готов, перейдите в раздел конвейеров в Azure Devops и создайте новый конвейер.
Затем укажите расположение кода. Обратите внимание, что на самом деле нет необходимости использовать репозитории Azure GIT, поэтому вы можете просто использовать Azure DevOps для своих нужд CI / CD.
На следующем экране просто укажите параметр Конфигурация как код. Затем измените пул агентов на Hosted Ubuntu, если он еще не выбран, и перейдите к файлу YAML.
Вот и все! Теперь, когда вы сохраняете и ставите сборку в очередь, она запускается автоматически в первый раз. Вы можете увидеть этап сборки, а также увидеть экран результатов теста после сборки.
Заключение
Настройка конвейеров CI / CD в наши дни является обязательной не только для того, чтобы убедиться, что то, что вы доставляете, хорошего качества, но и для облегчения разработки после этой первоначальной настройки.
И когда есть бесплатные инструменты, такие как конвейеры Azure DevOps или Gitlab CI, которые позволяют любому быстро и бесплатно настраивать вещи, на самом деле нет причин не настраивать конвейер CI для ваших проектов.
Код, приведенный в этой статье, можно найти на моей странице Azure DevOps.
Вам нравится мой блог? Помогите поддержать его на Ko-FI.
Первоначально опубликовано на сайте kriss.tech 25 января 2019 г.