Implementar regras específicas de domínio ao criar testes personalizados

4 minutos

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

Executar um conjunto de testes específico. Após a instalação do toolkit de testes, é-lhe atribuído um conjunto de testes que serão executados. Esses testes estão localizados no seguinte diretório: <install directory>/arm-ttk/testcases/deploymentTemplate.

É possível personalizar esta experiência de execução de testes. Uma maneira de personalizar, como vimos na unidade anterior, é usando o -Test parâmetro. Também pode editar quais os testes que estão a ser executados ao remover ficheiros no diretório. Você pode ignorar testes específicos usando o -Skip parâmetro.
Criar e executar testes específicos do domínio. É possível criar um arquivo de teste para impor regras específicas do domínio. Esta unidade irá concentrar-se principalmente neste cenário.

Criar e executar os seus próprios testes

Decidiu criar o seu próprio teste específico do domínio. Existe um fluxo para criar e executar um teste desses:

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

Criar um teste personalizado

Um teste personalizado precisa ser colocado no diretório correto: <install directory>/arm-ttk/testcases/deploymentTemplate. Também precisa de seguir uma nomenclatura padrão com traços e o sufixo .test e terminar com .ps1. Um ficheiro de teste típico tem o seguinte aspeto:

Domain-Specific.test.ps1

Criação

Para criar um nome de ficheiro de teste, precisa de o escrever no PowerShell. As três partes de um ficheiro de teste são:

Documentação. Esta parte é opcional, mas adicioná-la é muito vantajoso. Encontra-se na parte superior do ficheiro e, normalmente, tem um conjunto de comentários que descrevem o teste, o que faz e que nome lhe atribuir. Os comentários poderão ter um aspeto semelhante ao do exemplo seguinte:
```
<#
.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 breve descrição em uma seção chamada .Synopsis. Há também uma descrição mais longa em uma seção chamada .Description. Por último, há uma seção chamada .Example que mostra diferentes maneiras de executar o teste.
Parâmetros de entrada. O ficheiro de teste pode ter um conjunto de parâmetros de entrada. Esta secção é definida pela palavra-chave param e por parênteses. Pode ter o seguinte aspeto:
```
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, , $TemplateFileNamee $SampleName. Os dois primeiros parâmetros são obrigatórios, como mostra a Parameter[(Mandatory = $true)] decoração. Os parâmetros são nomeados de acordo com o seu significado. $TemplateObject Contém uma representação de objeto do arquivo de modelo e TemplateFileName contém o nome do arquivo que está sendo testado.

Gorjeta

Há mais informações sobre parâmetros no artigo Kit de ferramentas de teste de modelo ARM.
Lógica do teste. A última parte de um teste é a lógica do teste. Normalmente, a maioria dos testes pretende realizar os seguintes passos:
1. Iterar através do modelo.
2. Verificar uma ou mais condições.
3. Gerar um erro se algo estiver incorreto.

Programas auxiliares de código

Existem imensos programas auxiliares que o ajudam a localizar os conteúdos necessários e reportar quaisquer erros. Seguem-se dois exemplos de programas auxiliares de código:

Find-JsonContent. Ajuda a localizar um elemento específico com um determinado valor. Eis um exemplo:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
O código anterior ajuda a encontrar um atributo JSON com o nome apiVersion e um valor de *, que essencialmente significa todos os atributos nomeados apiVersion. Ele corresponderia a um objeto JSON como este:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Ajuda a comunicar ao executor de testes que algo está incorreto no modelo. Pode utilizá-lo para expressar uma mensagem de erro e interpolar uma expressão de cadeia com quaisquer variáveis necessárias. Eis um exemplo de como o utilizar:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Executar o teste

Neste ponto, você criou seu teste. Este será executado em conjunto com todos os outros ficheiros no mesmo diretório.

Como no exemplo anterior, você pode optar por executar apenas seu arquivo de teste específico usando o -Test parâmetro. Como parâmetro, você daria a ele o nome do arquivo de teste despojado das extensões de arquivo. Em seguida, Custom-Test.test.ps1 seria executado isoladamente através de Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Continuar