Implementar regras específicas de domínio por meio da criação de testes personalizados

4 minutos

Até agora, você examinou como executar alguns testes nos seus modelos. No entanto, você pode operar em uma empresa ou uma equipe que tenha o próprio conjunto de regras. Essas regras podem significar que você deseja personalizar a experiência de teste. Você pode ter os seguintes cenários:

Executar um conjunto de testes específico. Após a instalação do kit de ferramentas de teste, você receberá um conjunto de testes que será executado. Esses testes estão localizados no seguinte diretório: <install directory>/arm-ttk/testcases/deploymentTemplate.

É possível personalizar essa experiência de execução de teste. Uma forma de personalizá-la, como vimos na unidade anterior, é usando o parâmetro -Test. Você também pode editar quais testes são executados removendo arquivos no diretório. Você pode ignorar testes específicos usando o parâmetro -Skip.
Criar e executar testes específicos de domínio. É possível criar um arquivo de teste para impor regras específicas do domínio. Esta unidade terá como foco principalmente esse cenário.

Como criar e executar os próprios testes

Você decidiu criar o próprio teste específico de domínio. Há um fluxo para criar e executar esse teste:

Crie um arquivo no diretório <install directory>/arm-ttk/testcases/deploymentTemplate.
Crie o arquivo no PowerShell.
Execute o arquivo e inspecione os resultados.

Como criar um teste personalizado

Um teste personalizado precisa ser colocado no diretório correto: <install directory>/arm-ttk/testcases/deploymentTemplate. Ele também precisa seguir um padrão de nomenclatura com traços, um sufixo .test e terminar em .ps1. Um arquivo de teste típico é semelhante a:

Domain-Specific.test.ps1

Criação

Para criar um nome de arquivo de teste, você precisará escrevê-lo no PowerShell. As três partes de um arquivo de teste são:

Documentação. Essa parte é opcional, mas altamente vantajosa de ser adicionada. Ela reside na parte superior do arquivo e geralmente contém um conjunto de comentários que descrevem o que é o teste, o que ele faz e como chamá-lo. Os comentários podem ser semelhantes ao seguinte exemplo:
```
<#
.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
#>
```
O exemplo anterior descreve o que o teste faz em uma descrição resumida de uma seção chamada .Synopsis. Também há uma descrição mais longa em uma seção chamada .Description. Por fim, há uma seção chamada .Example que mostra diferentes maneiras de executar o teste.
Parâmetros de entrada. O arquivo de teste pode ter um conjunto de parâmetros de entrada. Essa seção é definida pela palavra-chave param e parênteses. Normalmente, ela pode ter a seguinte aparência:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

   [Parameter(Mandatory=$true)]
   [string]$TemplateFileName,

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
O exemplo anterior mostra três parâmetros: $TemplateObject, $TemplateFileName e $SampleName. Os dois primeiros parâmetros são obrigatórios, conforme mostrado pela decoração Parameter[(Mandatory = $true)]. Os parâmetros são nomeados de acordo com o significado deles. $TemplateObject contém uma representação de objeto do arquivo de modelo e TemplateFileName contém o nome do arquivo que está sendo testado.

Dica

Há mais informações sobre parâmetros no artigo Kit de ferramentas de teste do modelo do ARM.
Lógica de teste. A última parte de um teste é a lógica dele. No geral, a maioria dos testes tem como objetivo executar as seguintes etapas:
1. Iterar no modelo.
2. Confirmar uma ou mais condições.
3. Gerar um erro se algo incorreto for encontrado.

Auxiliares de código

Há muitos auxiliares que ajudarão você a encontrar o conteúdo de que precisa e relatar erros. Aqui estão dois exemplos de auxiliares de código:

Find-JsonContent. Ajuda você a localizar um elemento específico com um valor específico. Veja um exemplo:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
O código anterior ajuda a localizar um atributo JSON com o nome apiVersion e um valor de *, que essencialmente indica todos os atributos chamados apiVersion. Ele corresponderá a um objeto JSON como este:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Ajuda você a se comunicar com o executor de teste, indicando que algo está incorreto no modelo. Você pode usá-lo para expressar uma mensagem de erro e interpolar a expressão de cadeia de caracteres com qualquer variável necessária. Este é um exemplo de como usá-lo:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Executar o teste

Neste ponto, você criou o teste. Ele será executado com todos os outros arquivos no mesmo diretório.

Assim como ocorreu com o exemplo anterior, você pode optar por executar apenas o arquivo de teste específico usando o parâmetro -Test. Como parâmetro, você forneceria a ele o nome do arquivo de teste sem as extensões de arquivo. Custom-Test.test.ps1 seria executado sozinho por meio de Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Continuar