Реализация правил для конкретной предметной области путем разработки пользовательских тестов

Завершено

На данный момент вы узнали, как выполнять тесты применительно к шаблонам. Однако вы можете работать в компании или команде, имеющей собственный набор правил. Это значит, что необходимо настроить процесс тестирования. Возможны следующие сценарии:

  • Выполнение определенного набора тестов. После установки набора средств для тестирования вы получаете набор выполняемых им тестов. Они находятся в следующем каталоге: <install directory>/arm-ttk/testcases/deploymentTemplate.

    Однако тестовый запуск можно настроить. Одним из способов настройки, как вы увидели в предыдущем уроке, является использование параметра -Test. Вы также можете изменить выполняемые тесты, удалив файлы из указанного каталога. Вы можете пропустить определенные тесты с помощью параметра -Skip.

  • Разработка и выполнение тестов, связанных с предметной областью. Чтобы принудительно применить правила в определенной предметной области, можно создать тестовый файл. Данный раздел будет посвящен преимущественно этому сценарию.

Разработка и выполнение собственных тестов

Вы решили создать собственный тест для конкретной предметной области. Существует последовательность для создания и выполнения такого теста:

  1. Создайте файл в каталоге <install directory>/arm-ttk/testcases/deploymentTemplate.
  2. Создайте содержимое файла в PowerShell.
  3. Выполните файл и просмотрите результаты.

Создание пользовательского теста

Пользовательский тест должен находиться в соответствующем каталоге: <install directory>/arm-ttk/testcases/deploymentTemplate. Он также должен отвечать стандарту именования: в нем должны использоваться дефисы, он должен иметь постфикс .test и расширение .ps1. Типичный тестовый файл выглядит следующим образом:

Domain-Specific.test.ps1

Разработка

Содержимое файла теста необходимо написать в PowerShell. Ниже приведены три части тестового файла.

  • Документация. Эта часть является необязательной, но ее очень желательно добавить. Она находится в начале файла и обычно состоит из набора комментариев, описывающих тест, его назначение и способ вызова. Комментарии могут выглядеть, как в показано ниже:

    <#
    .Synopsis
         Ensures that all IDs use the resourceID() function.
    .Description
         Ensures that all IDs use the resourceID() function, or resolve to parameters or variables that use the ResourceID() function.
    .Example
         Test-AzTemplate -TemplatePath .\100-marketplace-sample\ -Test IDs-Should-Be-Derived-From-ResourceIDs
    #>
    

    В предыдущем примере назначение теста кратко описывается в разделе .Synopsis. В разделе .Description приводится более развернутое описание. Наконец, в разделе .Example показаны различные способы выполнения данного теста.

  • Входные параметры. Тестовый файл может иметь набор входных параметров. Этот раздел определяется ключевым словом param и круглыми скобками. Обычно он выглядит следующим образом:

    param(
       [Parameter(Mandatory=$true)]
       [PSObject]$TemplateObject,
    
       [Parameter(Mandatory=$true)]
       [string]$TemplateFileName,
    
       [string]$SampleName = "$ENV:SAMPLE_NAME"
    )
    

    В предыдущем примере показаны три параметра: $TemplateObject, $TemplateFileName и $SampleName. Первые два параметра являются обязательными, на что указывает декорирование Parameter[(Mandatory = $true)]. Параметры именуются в соответствии со значением. $TemplateObject содержит объектное представление файла шаблона, а TemplateFileName — имя тестируемого файла.

    Совет

    Дополнительные сведения о параметрах см. в статье о наборе средств для тестирования шаблонов ARM.

  • Логика теста. Последняя часть теста — собственно его логика. Большинство тестов обычно выполняют следующие действия:

    1. выполняют итерацию по шаблону;
    2. проверяют одно или несколько условий;
    3. выдают ошибку при обнаружении отклонений.

Вспомогательные функции кода

Существует множество вспомогательных функций, которые помогают находить нужное содержимое и сообщать об ошибках. Ниже приведены два примера таких функций.

  • Find-JsonContent. Эта вспомогательная функция помогает найти определенный элемент с указанным значением. Приведем пример:

    Find-JsonContent -Key apiVersion -Value * -Like
    

    Приведенный выше код помогает найти атрибут JSON с именем apiVersion и значением *, что фактически означает все атрибуты с именами apiVersion. То есть будет найден, например, такой объект JSON:

    {
       "apiVersion": "2021-01-01"
    }
    
  • Write-Error. Это вспомогательная функция, которая помогает сообщить пользователю, выполняющему тесты, что в шаблоне есть ошибки. Ее можно использовать для вывода сообщения об ошибке с включением в строковое выражение любых необходимых переменных. Вот пример ее использования:

      Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
    

Запуск теста

Итак, вы создали тест. Он будет выполняться вместе со всеми остальными файлами в том же каталоге.

Как и в случае с предыдущим примером, можно выбрать для запуска только определенный файл теста с помощью параметра -Test. В качестве параметра ему можно присвоить имя файла теста без расширения. Поэтому для запуска файла Custom-Test.test.ps1 можно использовать команду Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.