Implementieren von domänenspezifischen Regeln durch Erstellen von benutzerdefinierten Tests

4 Minuten

Bisher haben Sie sich mit dem Ausführen einiger Tests für Ihre Vorlagen beschäftigt. Möglicherweise arbeiten Sie jedoch in einem Unternehmen oder Team mit eigenen Regeln. Diese Regeln könnten dazu führen, dass Sie die Tests anpassen möchten. Die folgenden Szenarios sind möglich:

Ausführen einer bestimmten Testsammlung. Bei der Installation des Testtoolkits erhalten Sie eine Reihe von Tests, die ausgeführt werden. Diese Tests befinden sich im folgenden Verzeichnis: <install directory>/arm-ttk/testcases/deploymentTemplate.

Sie können diese Testausführungen anpassen. Eine Anpassungsmöglichkeit ist die Verwendung des Parameters -Test, wie in der vorherigen Lerneinheit erläutert. Sie können auch bearbeiten, welche Tests ausgeführt werden, indem Sie die entsprechenden Dateien im Verzeichnis entfernen. Sie können bestimmte Tests mit dem Parameter -Skip überspringen.
Sie erstellen domänenspezifische Tests und führen diese aus. Es ist möglich, eine Testdatei zu erstellen, um domänenspezifische Regeln zu erzwingen. In dieser Lerneinheit wird hauptsächlich dieses Szenario behandelt.

Erstellen und Ausführen eigener Tests

Sie haben sich entschieden, einen eigenen domänenspezifischen Test zu erstellen. Es gibt einen bestimmten Ablauf zum Erstellen und Ausführen eines solchen Tests:

Erstellen Sie im Verzeichnis <install directory>/arm-ttk/testcases/deploymentTemplate eine Datei.
Schreiben Sie die Datei in PowerShell.
Führen Sie die Datei aus, und überprüfen Sie die Ergebnisse.

Erstellen eines benutzerdefinierten Tests

Benutzerdefinierte Tests müssen sich im richtigen Verzeichnis befinden, nämlich in <install directory>/arm-ttk/testcases/deploymentTemplate. Außerdem müssen sie einem Benennungsstandard entsprechen, bei dem Bindestriche verwendet werden sowie das Postfix .test und die Endung .ps1. Eine typische Testdatei sieht folgendermaßen aus:

Domain-Specific.test.ps1

Erstellen

Wenn Sie einen Testdateinamen erstellen möchten, müssen Sie diesen in PowerShell schreiben. Die drei Bestandteile einer Testdatei sind:

Dokumentation: Dieser Teil ist optional, ist allerdings sehr von Vorteil. Er befindet sich am Anfang der Datei und enthält normalerweise eine Reihe von Kommentaren, die den Test beschreiben sowie wie er funktioniert und wie er aufgerufen wird. Die Kommentare können wie im folgenden Beispiel aussehen:
```
<#
.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
#>
```
Im Beispiel oben wird in einem Abschnitt namens .Synopsis kurz beschrieben, wie der Test funktioniert. Außerdem ist eine längere Beschreibung im Abschnitt .Description enthalten. Darüber hinaus gibt es einen Abschnitt .Example, in dem schließlich verschiedene Möglichkeiten zum Ausführen des Tests gezeigt werden.
Eingabeparameter: Die Testdatei kann über eine Reihe von Eingabeparametern verfügen. Dieser Abschnitt wird durch das Schlüsselwort param und Klammern definiert. Er sieht in der Regel ähnlich wie im folgenden Beispiel aus:
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
Das Beispiel oben enthält drei Parameter: $TemplateObject, $TemplateFileName und $SampleName. Die ersten beiden Parameter sind obligatorisch, wie die Ergänzung Parameter[(Mandatory = $true)] zeigt. Die Parameter werden entsprechend ihrer Bedeutung benannt. $TemplateObject enthält eine Objektdarstellung der Vorlagendatei und TemplateFileName den Namen der getesteten Datei.

Tipp

Weitere Informationen zu Parametern finden Sie im Artikel Testtoolkit für ARM-Vorlagen.
Testlogik: Der letzte Teil eines Tests ist die Testlogik. In den meisten Tests sollen die folgenden Schritte ausgeführt werden:
1. Durchlaufen der Vorlage
2. Überprüfen einer oder mehrerer Bedingungen
3. Auslösen eines Fehlers, wenn ein Fehler gefunden wird.

Codehilfsprogramme

Es gibt zahlreiche Hilfsprogramme, die Ihnen beim Suchen des benötigten Inhalts sowie beim Melden von Fehlern helfen. Hier zwei Beispiele für Codehilfsprogramme:

Find-JsonContent: Dieses Hilfsprogramm unterstützt Sie dabei, ein bestimmtes Element mit einem bestimmten Wert zu finden. Hier sehen Sie ein Beispiel:
```
Find-JsonContent -Key apiVersion -Value * -Like
```
Der Code oben hilft Ihnen bei der Suche nach einem JSON-Attribut namens apiVersion mit dem Wert *, was im Prinzip heißt, nach allen Attributen mit dem Namen apiVersion. Er würde beispielsweise das folgende JSON-Objekt zurückgeben:
```
{
   "apiVersion": "2021-01-01"
}
```
Write-Error. Ein Hilfsprogramm, mit dem Sie dem Testprogramm mitteilen können, dass etwas in der Vorlage falsch ist. Sie können es verwenden, um eine Fehlermeldung auszugeben und einen Zeichenfolgenausdruck mit allen benötigten Variablen zu interpolieren. Hier ein Verwendungsbeispiel:
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Ausführen des Tests

An diesem Punkt haben Sie Ihren Test erstellt. Sie wird zusammen mit allen anderen Dateien im selben Verzeichnis ausgeführt.