Implémenter des règles spécifiques à un domaine en créant des tests personnalisés

4 minutes

Jusqu’à présent, vous avez vu comment exécuter des tests sur vos modèles. Vous pouvez cependant travailler dans une société ou avec une équipe qui dispose de son propre ensemble de règles. Ces règles peuvent signifier que vous voulez personnaliser l’expérience de test. Vous pouvez avoir les scénarios suivants :

Exécutez une suite de tests spécifique. Lors de l’installation du Kit de ressources de test, vous disposez d’un ensemble de tests qui seront exécutés. Ces tests se trouvent dans le répertoire suivant : <répertoire d’installation>/arm-ttk/testcases/deploymentTemplate.

Il est possible de personnaliser cette expérience de série de tests. Une des possibilités de personnalisation est, comme nous l’avons vu dans l’unité précédente, d’utiliser le paramètre -Test. Vous pouvez également modifier les tests qui sont exécutés en supprimant des fichiers dans le répertoire. Vous pouvez ignorer des tests particuliers au moyen du paramètre -Skip.
Créer et exécuter des tests spécifiques à un domaine. Il est possible de créer un fichier de test pour appliquer des règles spécifiques à un domaine. Cette unité se concentrera principalement sur ce scénario.

Création et exécution de vos propres tests

Vous avez décidé de créer votre propre test spécifique à un domaine. Il existe un processus de création et d’exécution de ce type de test :

Créez un fichier dans le répertoire <répertoire d’installation>/arm-ttk/testcases/deploymentTemplate.
Créez le fichier dans PowerShell.
Exécutez le fichier et inspectez les résultats.

Création d’un test personnalisé

Un test personnalisé doit être placé dans le répertoire approprié : <répertoire d’installation>/arm-ttk/testcases/deploymentTemplate. Il doit également suivre un standard de nommage avec des tirets et le suffixe .test, et se terminer par .ps1. Un fichier de test typique ressemble à ceci :

Domain-Specific.test.ps1

Création

Pour créer un nom de fichier de test, vous devez l’écrire dans PowerShell. Les trois éléments d’un fichier de test sont les suivants :

Documentation. Cette partie est facultative mais il est très bénéfique de l’ajouter. Elle se trouve en haut du fichier et contient généralement un ensemble de commentaires décrivant le test, ce qu’il fait et comment l’appeler. Les commentaires peuvent se présenter comme dans l’exemple suivant :
```
<#
.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
#>
```
L’exemple précédent contient une courte description de ce que fait le test dans une section nommée .Synopsis. Il y a également une description plus longue dans une section nommée .Description. Enfin, il existe une section nommée .Example, qui montre différentes façons d’exécuter le test.
Paramètres d’entrée. Le fichier de test peut avoir un ensemble de paramètres d’entrée. Cette section est définie par le mot clé param et des parenthèses. Elle peut se présenter comme suit :
```
param(
   [Parameter(Mandatory=$true)]
   [PSObject]$TemplateObject,

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

   [string]$SampleName = "$ENV:SAMPLE_NAME"
)
```
L’exemple précédent montre trois paramètres : $TemplateObject, $TemplateFileName et $SampleName. Les deux premiers paramètres sont obligatoires, comme l’indique la décoration Parameter[(Mandatory = $true)]. Les paramètres sont nommés en fonction de leur signification. $TemplateObject contient une représentation objet du fichier de modèle, et TemplateFileName contient le nom du fichier à tester.

Conseil

Vous trouverez plus d’informations sur les paramètres dans l’article sur le kit de ressources de test de modèle ARM.
Logique du test. La dernière partie d’un test est la logique du test. La plupart des tests effectuent généralement les étapes suivantes :
1. Parcourir le modèle.
2. Vérifier une ou plusieurs conditions.
3. Génère une erreur si un événement est incorrect.

Applications auxiliaires pour le code

Il existe de nombreuses applications auxiliaires qui vous aideront à trouver le contenu dont vous avez besoin et à signaler les erreurs éventuelles. Voici deux exemples d’applications auxiliaires de code :

Find-JsonContent. Vous aide à localiser un élément spécifique avec une valeur spécifique. Voici un exemple :
```
Find-JsonContent -Key apiVersion -Value * -Like
```
Le code précédent permet de trouver un attribut JSON portant le nom apiVersion avec la valeur *, ce qui veut dire tous les attributs nommés apiVersion. Il trouverait des correspondances avec un objet JSON comme celui-ci :
```
{
   "apiVersion": "2021-01-01"
}
```
Erreur d’écriture. Vous permet d’indiquer à la personne effectuant le test que quelque chose est incorrect dans le modèle. Vous pouvez l’utiliser pour exprimer un message d’erreur et insérer dans une expression de chaîne des variables dont vous avez besoin. Voici un exemple de son utilisation :
```
  Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
```

Exécuter le test

À ce stade, vous avez créé votre test. Il sera exécuté avec tous les autres fichiers du même répertoire.

À l’instar de l’exemple précédent, vous pouvez choisir d’exécuter uniquement votre fichier de test spécifique en utilisant le paramètre -Test. En tant que paramètre, vous lui donneriez le nom de fichier de test, sans les extensions de fichier. Custom-Test.test.ps1 est exécuté par lui-même par le biais de Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Commentaires

Cette page a-t-elle été utile ?