Implementación de reglas específicas de dominio mediante la creación de pruebas personalizadas

4 minutos

Hasta ahora ha visto cómo ejecutar algunas pruebas en las plantillas. Sin embargo, es posible que trabaje como una empresa o un equipo que tenga un conjunto de reglas propio. Estas reglas pueden significar que desea personalizar la experiencia de prueba. Podría tener los escenarios siguientes:

Ejecute un conjunto de pruebas específico. Tras la instalación del kit de herramientas para pruebas, se le proporciona un conjunto de pruebas para ejecutarlas. Estas pruebas se encuentran en el directorio siguiente: <install directory>/arm-ttk/testcases/deploymentTemplate.

Esta experiencia de serie de pruebas se puede personalizar. Una forma de hacerlo, como ha visto en la unidad anterior, consiste en usar el parámetro -Test. También puede editar las pruebas que se ejecutan si quita archivos del directorio. Puede omitir pruebas específicas mediante el parámetro -Skip.
Cree y ejecute pruebas específicas del dominio. Es posible crear un archivo de prueba para aplicar reglas específicas del dominio. Esta unidad se centrará principalmente en este escenario.

Creación y ejecución de pruebas propias

Ha decidido crear una prueba propia específica de dominio. Existe un flujo para crear y ejecutar esta prueba:

Cree un archivo en el directorio <directorio de instalación>/arm-ttk/testcases/deploymentTemplate.
Cree el archivo en PowerShell.
Ejecute el archivo e inspeccione los resultados.

Creación de una prueba personalizada

Es necesario colocar una prueba personalizada en el directorio correcto: <install directory>/arm-ttk/testcases/deploymentTemplate. También debe seguir un estándar de nomenclatura que incluya guiones, un postfijo de .test y finalice en .ps1. Un archivo de prueba típico tiene este aspecto:

Domain-Specific.test.ps1

Creación

Para crear un nombre de archivo de prueba, debe escribirlo en PowerShell. Las tres partes de un archivo de prueba son:

Documentación. Esta parte es opcional, pero es muy recomendable agregarla. Se sitúa en la parte superior del archivo y suele constar de un conjunto de comentarios que describen la prueba, lo que hace y cómo llamarla. Los comentarios pueden tener un aspecto similar al ejemplo siguiente:
```
<#
.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
#>
```
En el ejemplo anterior se describe de forma breve lo que hace la prueba en una sección denominada .Synopsis. También hay una descripción más larga en una sección denominada .Description. Por último, hay una sección denominada .Example en la que se muestran diferentes formas de ejecutar la prueba.
Parámetros de entrada. El archivo de prueba puede tener un conjunto de parámetros de entrada. Esta sección se define mediante el parámetro de palabra clave y los paréntesis. Normalmente, puede tener este aspecto:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
En el ejemplo anterior se muestran tres parámetros: $TemplateObject, $TemplateFileName y $SampleName. Los dos primeros parámetros son obligatorios, como se muestra en la decoración Parameter[(Mandatory = $true)]. A los parámetros se les asigna un nombre según su significado. $TemplateObject contiene una representación de objeto del archivo de plantilla y TemplateFileName contiene el nombre del archivo que se va a probar.

Sugerencia

Hay más información sobre los parámetros en el artículo Kit de herramientas de pruebas de plantillas de ARM.
Lógica de prueba. La última parte de una prueba es la lógica de prueba. Normalmente, la mayoría de las pruebas realizan estos pasos:
1. Iterar por la plantilla.
2. Comprobar una o varias condiciones.
3. Genere un error si hay algo incorrecto.

Aplicaciones auxiliares de código

Hay muchas aplicaciones auxiliares que le ayudarán a encontrar el contenido que necesita y a notificar los errores. Aquí tiene dos ejemplos de aplicaciones auxiliares de código:

Find-JsonContent. Ayuda a localizar un elemento específico con un valor específico. Veamos un ejemplo:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
El código anterior ayuda a encontrar un atributo JSON con el nombre apiVersion y un valor de *, que básicamente significa todos los atributos denominados apiVersion. Coincidiría con un objeto JSON similar a este:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Ayuda a notificar al ejecutor de la prueba que hay algo incorrecto en la plantilla. Se puede usar para expresar un mensaje de error e interpolar una expresión de cadena con las variables que necesite. Este es un ejemplo de cómo se usa:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Ejecución de la prueba

En este punto, ha creado la prueba. Se ejecutará junto con todos los demás archivos del mismo directorio.

Como sucede con el ejemplo anterior, puede optar por ejecutar solo el archivo de prueba específico mediante el parámetro -Test. Como parámetro, le daría el nombre de archivo de prueba sin las extensiones de archivo. Custom-Test.test.ps1 entonces se ejecutaría por sí mismo a través de Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Comentarios

¿Le ha resultado útil esta página?