Implementare regole specifiche del dominio creando test personalizzati

4 minuti

Finora si è appreso come eseguire alcuni test sui modelli. Se però si lavora in un'azienda o in un team che ha il proprio set di regole specifiche, si potrebbe voler personalizzare l'esperienza di test in base a queste regole. Ecco gli scenari possibili:

Eseguire un gruppo di test specifico. L'installazione del toolkit di test include un set di test che verranno eseguiti. Questi test si trovano nella directory: <install directory>/arm-ttk/testcases/deploymentTemplate.

È possibile personalizzare questa esperienza di esecuzione dei test. Una modalità di personalizzazione, come si è visto nell'unità precedente, consiste nell'uso del parametro -Test. È anche possibile modificare i test da eseguire rimuovendo i file nella directory. È possibile ignorare test specifici usando il parametro -Skip.
Creare ed eseguire test specifici del dominio. È possibile creare un file di test per applicare regole specifiche del dominio. Questa unità è incentrata principalmente su questo scenario.

Creazione ed esecuzione di test personalizzati

Si è deciso di creare un test specifico del proprio dominio. È disponibile un flusso per la creazione e l'esecuzione del test:

Creare un file nella directory <install directory>/arm-ttk/testcases/deploymentTemplate.
Creare il file in PowerShell.
Eseguire il file ed esaminare i risultati.

Creazione di un test personalizzato

Un test personalizzato deve essere inserito nella directory corretta: <install directory>/arm-ttk/testcases/deploymentTemplate. Deve inoltre seguire uno standard di denominazione con trattini e il suffisso .test e terminare con .ps1. Un file di test tipico è simile al seguente:

Domain-Specific.test.ps1

Creazione

Per creare un nome file di test, è necessario scriverlo in PowerShell. Le tre parti di un file di test sono:

Documentazione. Questa parte è facoltativa, ma la sua aggiunta offre numerosi vantaggi. Si trova all'inizio del file e in genere contiene una serie di commenti che descrivono il test, le operazioni eseguite dal test e come chiamarlo. I commenti potrebbero avere un aspetto simile all'esempio seguente:
```
<#
.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
#>
```
Il codice precedente descrive le operazioni eseguite dal test in una breve descrizione all'interno di una sezione denominata .Synopsis. È disponibile anche una descrizione più lunga in una sezione denominata .Description. È infine presente una sezione denominata .Example che mostra diverse modalità di esecuzione del test.
Parametri di input. Il file di test può avere un set di parametri di input. Questa sezione è definita dalla parola chiave param e dalle parentesi. In genere ha un aspetto simile al seguente:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
L'esempio precedente mostra tre parametri: $TemplateObject, $TemplateFileName e $SampleName. I primi due parametri sono obbligatori, come illustrato dalla decorazione Parameter[(Mandatory = $true)]. I parametri vengono denominati in base al loro significato. $TemplateObject contiene una rappresentazione in forma di oggetto del file modello e TemplateFileName contiene il nome del file da testare.

Suggerimento

Altre informazioni sui parametri sono disponibili nell'articolo Usare il toolkit di test dei modelli di Resource Manager.
Logica del test. L'ultima parte di un test è la logica del test. La maggior parte dei test è costituita in genere dai passaggi seguenti:
1. Iterazione del modello.
2. Verifica di una o più condizioni.
3. Generazione di un errore se sono presenti elementi non corretti.

Helper per il codice

Sono disponibili numerosi helper che consentono di trovare il contenuto necessario e segnalare eventuali errori. Di seguito sono riportati due esempi di helper per il codice:

Find-JsonContent. Consente di individuare un elemento specifico con un valore specifico. Ecco un esempio:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
Il codice precedente consente di trovare un attributo JSON con nome apiVersion e valore *, che essenzialmente equivale a tutti gli attributi con nome apiVersion. L'oggetto JSON corrispondente sarebbe simile al seguente:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Consente di comunicare allo strumento di esecuzione dei test che il modello contiene uno o più elementi non corretti. È possibile usarlo per esprimere un messaggio di errore e interpolare un'espressione stringa con le variabili necessarie. Ecco un esempio di come usarlo:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Eseguire il test

A questo punto, il test è stato creato. Verrà eseguito insieme a tutti gli altri file nella stessa directory.