Poprzednie

Następne

Implementowanie reguł specyficznych dla domeny za pomocą tworzenia testów niestandardowych

Ukończone

Do tej pory omówiliśmy sposób uruchamiania niektórych testów na szablonach. Możesz jednak działać w firmie lub zespole, który ma własny zestaw reguł. Ze względu na te reguły może być konieczne dostosowanie środowiska testowego. Rozważ następujące scenariusze:

• Uruchamianie zestawu specyficznych testów Po zainstalowaniu zestawu narzędzi do testowania otrzymasz zestaw testów, które zostaną uruchomione. Te testy znajdują się w następującym katalogu: <install directory>/arm-ttk/testcases/deploymentTemplate.

  Możliwe jest dostosowanie tego środowiska uruchamiania testów. Jednym ze sposobów dostosowywania, jak pokazano w poprzedniej lekcji, jest użycie parametru -Test . Możesz również edytować, które testy są uruchamiane, usuwając pliki w katalogu. Konkretne testy można pominąć przy użyciu parametru -Skip .

• Tworzenie i uruchamianie testów specyficznych dla dziedziny. Istnieje możliwość utworzenia pliku testowego w celu wymuszania reguł specyficznych dla domeny. W tej lekcji skupimy się głównie na tym scenariuszu.

Tworzenie i uruchamianie własnych testów

Chcesz utworzyć własny test specyficzny dla dziedziny. Istnieje przepływ do tworzenia i uruchamiania takiego testu:

1. Utwórz plik w <katalogu install directory>/arm-ttk/testcases/deploymentTemplate.
2. Utwórz plik w programie PowerShell.
3. Uruchom ten plik i sprawdź wyniki.

Tworzenie testu niestandardowego

Test niestandardowy musi zostać umieszczony w poprawnym katalogu: <install directory>/arm-ttk/testcases/deploymentTemplate. Ponadto nazwa pliku musi być zgodna ze standardem nazewnictwa: musi zawierać kreski i przyrostek .test oraz kończyć się na .ps1. Typowy plik testowy wygląda następująco:

Domain-Specific.test.ps1

Tworzenie

Aby utworzyć nazwę pliku testowego, należy napisać ją w programie PowerShell. Plik testowy składa się z trzech części:

• Dokumentacja. Ta część jest opcjonalna, ale dodanie jej może być bardzo korzystne. Znajduje się w górnej części pliku i zwykle składa się z zestawu komentarzy opisujących test oraz jego sposób działania i wywoływania. Komentarze mogą wyglądać podobnie jak w poniższym przykładzie:

  <#
  .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
  #>
  

  W poprzednim przykładzie opisano, co test wykonuje w krótkim opisie w sekcji o nazwie .Synopsis. Istnieje również dłuższy opis w sekcji o nazwie .Description. Na koniec istnieje sekcja o nazwie .Example , która pokazuje różne sposoby uruchamiania testu.

• Parametry wejściowe. Plik testowy może mieć zestaw parametrów wejściowych. Ta sekcja jest definiowana przez słowo kluczowe param i nawiasy. Zwykle wygląda następująco:

  param(
     [Parameter(Mandatory=$true)]
     [PSObject]$TemplateObject,
  
     [Parameter(Mandatory=$true)]
     [string]$TemplateFileName,
  
     [string]$SampleName = "$ENV:SAMPLE_NAME"
  )
  

  W poprzednim przykładzie przedstawiono trzy parametry: $TemplateObject, $TemplateFileNamei $SampleName. Pierwsze dwa parametry są obowiązkowe, jak pokazano w Parameter[(Mandatory = $true)] dekoracji. Parametry są nazwane zgodnie z ich znaczeniem. $TemplateObject zawiera reprezentację obiektu pliku szablonu i TemplateFileName zawiera nazwę testowanego pliku.

  Napiwek

  Więcej informacji na temat parametrów znajduje się w artykule Zestaw narzędzi do testowania szablonu usługi ARM.

• Logika testu. Ostatnia część testu jest logiką testu. Procedura większości testów wygląda następująco:

  1. Iterowanie po szablonie.
  2. Weryfikowanie jednego lub kilku warunków.
  3. Zgłoś błąd w przypadku znalezienia nieprawidłowości.

Pomocnicy kodu

Dostępnych jest wiele pomocników, które ułatwią znalezienie potrzebnej zawartości i raportowanie błędów. Poniżej przedstawiono dwa przykłady pomocników kodu:

• Find-JsonContent. Ułatwia znalezienie określonego elementu o określonej wartości. Oto przykład:

  Find-JsonContent -Key apiVersion -Value * -Like
  

  Powyższy kod ułatwia znalezienie atrybutu JSON o nazwie apiVersion i wartości *, co zasadniczo oznacza wszystkie atrybuty o nazwie apiVersion. Będzie on zgodny z obiektem JSON w następujący sposób:

  {
     "apiVersion": "2021-01-01"
  }
  

• Write-Error. Ułatwia przekazanie modułowi uruchamiającemu testy informacji o nieprawidłowościach w szablonie. Za jego pomocą można wyrazić komunikat o błędzie i interpolować to wyrażenie ciągu z dowolnymi zmiennymi, które są potrzebne. Oto przykład, jak go używać:

    Write-Error "Resource $($resource.Name) Location must be located in westeurope'" -TargetObject $resource
  

Uruchamianie testu

W tym momencie utworzono test. Zostanie on uruchomiony razem ze wszystkimi innymi plikami w tym samym katalogu.

Podobnie jak w poprzednim przykładzie, możesz zdecydować się na uruchomienie tylko określonego pliku testowego przy użyciu parametru -Test . Jako parametr nadalibyśmy mu nazwę pliku testowego pozbawionego rozszerzeń plików. Oznacza to, że sam plik Custom-Test.test.ps1 można uruchomić przy użyciu polecenia Test-AzTemplate -TemplatePath /path/to/template -Test Custom-Test.

Kontynuuj