Domeinspecifieke regels implementeren door aangepaste tests te ontwerpen

4 minuten

Tot nu toe hebt u gezien hoe u een aantal tests kunt uitvoeren op uw sjablonen. U kunt echter werken in een bedrijf of team dat een eigen set regels heeft. Deze regels kunnen betekenen dat u de testervaring wilt aanpassen . Er kan sprake zijn van de volgende scenario's:

Voer een specifiek testpakket uit. Na het installeren van de test-toolkit krijgt u een aantal tests om uit te voeren. Deze tests bevinden zich in de volgende map: <installatiemap>/arm-ttk/testcases/deploymentTemplate.

Het is mogelijk om de testervaring aan te passen. Een manier om aan te passen, zoals we in de vorige les hebben gezien, is met behulp van de -Test parameter. U kunt ook bewerken welke tests worden uitgevoerd door bestanden uit de map te verwijderen. U kunt specifieke tests overslaan met behulp van de -Skip parameter.
Domeinspecifieke tests maken en uitvoeren. Het is mogelijk om een testbestand te maken om domeinspecifieke regels af te dwingen. Deze les is voornamelijk gericht op dit scenario.

Uw eigen tests ontwerpen en uitvoeren

U hebt besloten om uw eigen domeinspecifieke test te ontwerpen. Er bestaat een stroom voor het maken en uitvoeren van een dergelijke test:

Maak een bestand in de map install directory<>/arm-ttk/testcases/deploymentTemplate.
Ontwerp het bestand in PowerShell.
Voer het bestand uit en controleer de resultaten.

Een aangepaste test maken

Er moet een aangepaste test in de juiste map worden geplaatst: < installeren>. Het moet ook een naamgevingsstandaard volgen met streepjes, een achtervoegsel van .test en een einde aan .ps1. Een gebruikelijk testbestand ziet er als volgt uit:

Domain-Specific.test.ps1

Ontwerpen

Voor het opgeven van een naam voor het testbestand moet u gebruikmaken van PowerShell. Het testbestand bestaat uit drie onderdelen:

Documentatie. Dit deel is optioneel, maar het is zeer handig om toe te voegen. Het bevindt zich bovenaan het bestand en bestaat meestal uit een set opmerkingen waarin wordt beschreven wat de test is, wat deze doet en hoe deze kan worden aangeroepen. De opmerkingen kunnen eruitzien als in het volgende voorbeeld:
```
<#
.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
#>
```
In het voorgaande voorbeeld wordt beschreven wat de test doet in een korte beschrijving in een sectie met de naam .Synopsis. Er is ook een langere beschrijving in een sectie met de naam .Description. Ten slotte ziet u een sectie met de naam .Example verschillende manieren om de test uit te voeren.
Invoerparameters. Het testbestand kan een set invoerparameters hebben. Deze sectie wordt gedefinieerd door de trefwoordparameter en haakjes. Dit kan er als volgt uitzien:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
In het voorgaande voorbeeld ziet u drie parameters: $TemplateObject, $TemplateFileNameen $SampleName. De eerste twee parameters zijn verplicht, zoals wordt weergegeven door de Parameter[(Mandatory = $true)] decoratie. De naam van parameters wordt bepaald een de hand van de betekenis. $TemplateObject bevat een objectweergave van het sjabloonbestand en TemplateFileName bevat de naam van het bestand dat wordt getest.

Aanbeveling

Er is meer informatie over parameters in het artikel test-toolkit voor ARM-sjablonen.
Testlogica. Het laatste deel van een test is de testlogica. Bij de meeste tests worden de volgende stappen uitgevoerd:
1. De sjabloon doorlopen.
2. Een of meer voorwaarden controleren.
3. Meld een fout als er iets niet klopt.

Code-helpers

Er zijn veel helpers die u helpen bij het vinden van de inhoud die u nodig hebt en het melden van mogelijke fouten. Hier volgen twee voorbeelden van code-helpers:

Find-JsonContent. Hiermee kunt u een specifiek element met een specifieke waarde vinden. Hier volgt een voorbeeld:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
De voorgaande code helpt bij het vinden van een JSON-kenmerk met de naam apiVersion en een waarde van *, wat in wezen alle kenmerken met de naam apiVersionbetekent. Dit komt overeen met een JSON-object als volgt:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Hiermee kunt u communiceren aan het testprogramma dat iets onjuist is in de sjabloon. U kunt deze gebruiken om een foutbericht op te stellen en de tekenreeksexpressie te interpoleren met de benodigde variabelen. Hier volgt een voorbeeld van het gebruik:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

De test uitvoeren

Op dit moment hebt u uw test gemaakt. Dit wordt uitgevoerd met alle andere bestanden in dezelfde map.

Net als in het vorige voorbeeld kunt u ervoor kiezen om alleen uw specifieke testbestand uit te voeren met behulp van de -Test parameter. Als parameter geeft u het de naam van het testbestand verwijderd van de bestandsextensies. Custom-Test.test.ps1 zou dan op zichzelf worden uitgevoerd via Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Feedback

Is deze pagina nuttig?