Implementera domänspecifika regler genom att redigera anpassade tester

4 minuter

Hittills har du lärt dig att köra vissa tester på dina mallar. Du kan dock arbeta i ett företag eller team som har en egen uppsättning regler. De här reglerna kan innebära att du vill anpassa testfunktionen. Tänk dig följande scenarier:

Köra en specifik serie tester. När du har installerat testverktyget får du en uppsättning tester som ska köras. Dessa tester finns i följande katalog: <installera directory>/arm-ttk/testcases/deploymentTemplate.

Du kan anpassa den här testmiljön. Ett sätt att anpassa, som vi har sett i föregående lektion, är att använda parametern -Test . Du kan även redigera vilka tester som ska köras genom att ta bort filer i katalogen. Du kan hoppa över specifika tester med hjälp av parametern -Skip .
Skapa och köra domänspecifika tester. Det är möjligt att skapa en testfil för att framtvinga domänspecifika regler. Den här lektionen handlar främst om det här scenariot.

Skriva och köra egna tester

Du har bestämt dig för att skriva ett eget domänspecifikt test. Det finns ett flöde för redigering och körning av ett sådant test:

Skapa en fil i katalogen <install directory>/arm-ttk/testcases/deploymentTemplate.
Redigera filen i PowerShell.
Köra filen och granska resultatet.

Skapa ett anpassat test

Ett anpassat test måste placeras i rätt katalog: <installera katalog>/arm-ttk/testcases/deploymentTemplate. Det måste även följa namngivningsregeln med bindestreck och postfixet .test samt sluta med .ps1. En typisk testfil ser ut så här:

Domain-Specific.test.ps1

Redigering

Om du vill redigera ett testfilnamn måste du skriva det i PowerShell. De tre delarna i en testfil är:

Dokumentation. Den här delen är valfri men mycket bra att lägga till. Den finns överst i filen och innehåller vanligtvis kommentarer som beskriver vad testet är, vad det gör och hur du anropar det. Kommentarerna kan se ut som i följande exempel:
```
<#
.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
#>
```
I föregående exempel beskrivs vad testet gör i en kort beskrivning i ett avsnitt med namnet .Synopsis. Det finns också en längre beskrivning i ett avsnitt med namnet .Description. Slutligen finns det ett avsnitt som heter .Example som visar olika sätt att köra testet.
Indataparametrar. Testfilen kan ha en uppsättning indataparametrar. Det här avsnittet definieras av nyckelordet param och parenteser. Det kan se ut så här:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
Föregående exempel visar tre parametrar: $TemplateObject, $TemplateFileNameoch $SampleName. De två första parametrarna är obligatoriska, vilket visas i dekorationen Parameter[(Mandatory = $true)] . Parametrarna namnges enligt deras innebörd. $TemplateObject innehåller en objektrepresentation av mallfilen och TemplateFileName innehåller namnet på filen som testas.

Dricks

Det finns mer information om parametrar i artikeln TESTverktyg för ARM-mallar.
Testlogik. Den sista delen i testet är testlogiken. De flesta tester utför vanligtvis följande steg:
1. Iterera genom mallen.
2. Verifiera ett eller flera villkor.
3. Utlös ett fel om något är felaktigt.

Hjälpkomponenter för kod

Det finns många hjälpkomponenter som hjälper dig att hitta det innehåll du behöver och att rapportera eventuella fel. Här följer två exempel på hjälpkomponenter för kod:

Find-JsonContent. Detta letar upp ett specifikt element med ett specifikt värde. Här är ett exempel:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
Föregående kod hjälper dig att hitta ett JSON-attribut med namnet apiVersion och värdet *, vilket i princip betyder alla attribut med namnet apiVersion. Det skulle matcha ett JSON-objekt så här:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Detta anger för den som kör testet att någonting är felaktigt i mallen. Du kan använda den till att skriva felmeddelanden och interpolera ett stränguttryck med de variabler du behöver. Här är ett exempel på hur du kan använda komponenten:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Kör testet

Nu har du skapat testet. Den kommer att köras tillsammans med alla andra filer i samma katalog.