Ćwiczenie — tworzenie i uruchamianie testów niestandardowych za pomocą zestawu narzędzi testowych

  • 5 min

Będąc członkiem zespołu produktowego, wiesz, że ważna jest możliwość implementowania reguł specyficznych dla zespołu lub dziedziny. Można to osiągnąć, implementując reguły jako testy. Następnie można uruchomić te testy za pomocą zestawu narzędzi do testowania.

Tworzenie i uruchamianie testu niestandardowego

Utworzysz niestandardowy test i uruchomisz go przy użyciu zestawu narzędzi do testowania. Poprawisz również szablon wdrożenia, aby zapewnić pomyślne wykonanie testu. Test niestandardowy będzie weryfikował, czy wszystkie parametry są zgodne z regułą nazewnictwa. Ta reguła jest wymaganiem specyficznym dla dziedziny dotyczącej produktu, nad którym pracujesz Ty i Twój zespół.

Zalecamy, aby w tym ćwiczeniu mieć otwarte dwa edytory tekstu.

  • Tworzenie testu niestandardowego Znajdź ścieżkę podkatalogu arm-ttk/testcases/deploymentTemplate/ katalogu instalacyjnego zestawu narzędzi do testowania. Teraz uruchomisz program Visual Studio Code, w którym utworzysz i edytujesz test niestandardowy.
  • Tworzenie pliku szablonu i uruchamianie testów. Wybierz lokalizację dla tej ścieżki. Zaleca się uruchomienie wystąpienia programu Visual Studio Code z tej ścieżki, aby można było łatwo edytować plik azuredeploy.json po wyświetleniu monitu. Wraz z tym wystąpieniem programu Visual Studio Code uruchom zintegrowany terminal, aby ułatwić uruchamianie testów.

Tworzenie pliku szablonu

Wybierz katalog i utwórz plik o nazwie azuredeploy.json.

Ostrzeżenie

Upewnij się, że wybrany katalog jest pusty i nie ma podkatalogów

Dodaj następującą zawartość:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": []
}

Tworzenie testu niestandardowego

  1. Otwórz program Visual Studio Code i przejdź do katalogu instalacyjnego zestawu narzędzi do testowania. Przejdź do podkatalogu arm-ttk/testcases/deploymentTemplate. Uruchom następujące polecenie:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  2. Utwórz niestandardowy plik testowy o nazwie Custom-ParameterNaming.test.ps1. Wstaw do tego pliku następującą zawartość:

    param(
[Parameter(Mandatory=$false,Position=0)] #not mandatory for case of an empty resource array
[PSObject]
$MainTemplateResources
)

Write-Error "To be implemented"

    Pozostaw otwarty edytor tekstu. Będziesz edytować ten plik później.

Uruchamianie testu niestandardowego

Uruchom test niestandardowy, wykonując następujące czynności:

  1. Otwórz nowe okno terminalu lub ponownie użyj starego.

  2. Przejdź do katalogu, w którym utworzono plik azuredeploy.json. Uruchom następujące polecenie, aby uruchomić program Visual Studio Code:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog szablonów, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  3. Z poziomu programu Visual Studio Code otwórz zintegrowany terminal, wybierając z menu głównego pozycję Terminal>Nowy terminal. Aby uruchomić powłokę programu PowerShell, uruchom w terminalu następujące polecenie:

    pwsh

    Wyświetlone dane wyjściowe będą podobne do następujących:

    PowerShell 7.0.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

  4. Uruchom polecenie Import-Module w terminalu.

    Uwaga

    Przed zaimportowaniem modułu zastąp ciąg patch/to/arm-ttk/arm-ttk.psd1 ścieżką do pobranego zestawu narzędzi do testowania.

    Import-Module path/to/arm-ttk/arm-ttk.psd1

    Napiwek

    Jeśli narzędzie zostanie pobrane lub sklonowane do katalogu Pobrane , ścieżka będzie wyglądać następująco: /Users/<user>/Downloads/arm-ttk/arm-ttk/arm-ttk.psd1.

    Teraz możesz przystąpić do korzystania z narzędzia. Dopóki jesteś w tej samej sesji programu PowerShell, nie ma potrzeby ponownego uruchamiania polecenia importowania.

  5. Uruchom polecenie Test-AzTemplate w terminalu, aby rozpocząć przebieg testu:

    Test-AzTemplate -TemplatePath .

    Dane wyjściowe są podobne do następujących. Zwróć uwagę na wyróżnione wiersze pokazujące test:

    Validating custom\azuredeploy.json
  JSONFiles Should Be Valid
    [+] JSONFiles Should Be Valid (56 ms)
Pass  : 1
Fail  : 0
Total : 1



  adminUsername Should Not Be A Literal
    [+] adminUsername Should Not Be A Literal (68 ms)
  apiVersions Should Be Recent In Reference Functions
    [+] apiVersions Should Be Recent In Reference Functions (203 ms)
  apiVersions Should Be Recent
    [+] apiVersions Should Be Recent (137 ms)
  artifacts parameter
    [+] artifacts parameter (145 ms)
  CommandToExecute Must Use ProtectedSettings For Secrets
    [+] CommandToExecute Must Use ProtectedSettings For Secrets (171 ms)
  deploymentTemplate
    [-] Custom ParameterNaming (354 ms)
        To be implemented

  DependsOn Best Practices
    [+] DependsOn Best Practices (152 ms)
  Deployment Resources Must Not Be Debug
    [+] Deployment Resources Must Not Be Debug (152 ms)
  DeploymentTemplate Must Not Contain Hardcoded Uri
    [+] DeploymentTemplate Must Not Contain Hardcoded Uri (185 ms)
  DeploymentTemplate Schema Is Correct
    [+] DeploymentTemplate Schema Is Correct (197 ms)
  Dynamic Variable References Should Not Use Concat
    [+] Dynamic Variable References Should Not Use Concat (157 ms)
  IDs Should Be Derived From ResourceIDs
    [+] IDs Should Be Derived From ResourceIDs (69 ms)
  Location Should Not Be Hardcoded
    [+] Location Should Not Be Hardcoded (260 ms)
  ManagedIdentityExtension must not be used
    [+] ManagedIdentityExtension must not be used (70 ms)
  Min And Max Value Are Numbers
    [+] Min And Max Value Are Numbers (213 ms)
  Outputs Must Not Contain Secrets
    [+] Outputs Must Not Contain Secrets (76 ms)
  Parameter Types Should Be Consistent
    [+] Parameter Types Should Be Consistent (68 ms)
  Parameters Must Be Referenced
    [+] Parameters Must Be Referenced (93 ms)
  Password params must be secure
    [+] Password params must be secure (111 ms)
  providers apiVersions Is Not Permitted
    [+] providers apiVersions Is Not Permitted (68 ms)
  ResourceIds should not contain
    [+] ResourceIds should not contain (210 ms)
  Resources Should Have Location
    [+] Resources Should Have Location (113 ms)
  Resources Should Not Be Ambiguous
    [+] Resources Should Not Be Ambiguous (147 ms)
  Secure Params In Nested Deployments
    [+] Secure Params In Nested Deployments (242 ms)
  Secure String Parameters Cannot Have Default
    [+] Secure String Parameters Cannot Have Default (129 ms)
  Template Should Not Contain Blanks
    [+] Template Should Not Contain Blanks (201 ms)
  URIs Should Be Properly Constructed
    [+] URIs Should Be Properly Constructed (180 ms)
  Variables Must Be Referenced
    [+] Variables Must Be Referenced (132 ms)
  Virtual Machines Should Not Be Preview
    [+] Virtual Machines Should Not Be Preview (91 ms)
  VM Images Should Use Latest Version
    [+] VM Images Should Use Latest Version (114 ms)
  VM Size Should Be A Parameter
    [+] VM Size Should Be A Parameter (130 ms)
Pass  : 31
Fail  : 1
Total : 32

    Po znalezieniu testu pozostaw to okno terminalu otwarte. Użyjesz go później.

Refaktoryzacja testu niestandardowego

Teraz nadasz testowi niestandardowemu prawidłową implementację.

  1. Wróć do edytora tekstu z plikiem Custom-ParameterNaming.test.ps1.

    Uwaga

    Jeśli przypadkowo zamknięto program Visual Studio Code, przejdź do podkatalogu arm-ttk/testcases/deploymentTemplate i otwórz plik Custom-ParameterNaming.test.ps1.

  2. Zastąp zawartość pliku następującym kodem:

    <#
.Synopsis
 Ensures that all parameters adheres to a naming standard
.Description
 All parameters should start with the company specific prefix 'tailwind'
#>
param(
   # The Template Object
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateObject,

   # The Template JSON Text
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateText
)

foreach ($parameter in $TemplateObject.parameters.psobject.properties) {
  # If the parameter name starts with tailwind, then the parameter is correctly named
  if ($parameter.Name -notmatch 'tailwind*') {
     Write-Error "Parameter '$($parameter.Name)' must start with prefix 'tailwind'" -TargetObject $parameter
  }
}

    Powyższy kod wykonuje iterację po wszystkich parametrach. Sprawdza atrybut name i sprawdza, czy nazwa zaczyna się od prefiksu tailwind. Jeśli sprawdzony parametr nie jest zgodny z regułą nazewnictwa, kod wywołuje Write-Error polecenie cmdlet z odpowiednim komunikatem o błędzie.

Aktualizowanie pliku szablonu

Teraz dodasz parametr do pliku szablonu.

  1. Wybierz edytor tekstu z plikiem azuredeploy.json i zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Poprzednia zawartość szablonu definiuje parametr o nazwie location , który nie spełnia reguły nazewnictwa, ponieważ nie ma prefiksu tailwind .

Ponowne uruchamianie zestawu narzędzi testowych

Masz teraz napisany test niestandardowy. Jednak nazewnictwo pliku szablonu nie spełnia wymagania. W związku z tym oczekujesz, że przebieg testu zakończy się niepowodzeniem. Upewnij się, że tak jest, wykonując następujący krok.

Użyj istniejącego okna zintegrowanego terminalu programu Visual Studio Code, w którym uruchomiono program PowerShell i zaimportowano zestaw narzędzi testowych.

W programie Visual Studio Code uruchom polecenie Test-AzTemplate w zintegrowanym terminalu.

Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

Poprzednie polecenie jest uruchamiane z parametrem -Test, który przyjmuje nazwę testu jako dane wejściowe. Custom-ParameterNaming Podano jako parametr, co oznacza, że zostanie uruchomiony tylko nowo utworzony test.

Napiwek

Użycie parametru -Test jest dobrym rozwiązaniem podczas opracowywania testu, ponieważ ogranicza to, co jest uruchamiane i rozmiar danych wyjściowych terminalu.

Wynikiem tego polecenia są następujące dane wyjściowe:

Validating custom\azuredeploy.json
 deploymentTemplate
   [-] Custom ParameterNaming (2ms)
       Parameter 'location' must start with prefix 'tailwind'

Wynik wskazuje, że test działa. Upewnijmy się, że tak jest, zmieniając plik wdrożenia.

Poprawianie pliku szablonu

Teraz chcesz sprawdzić poprawność testu niestandardowego, zmieniając plik szablonu tak, aby był zgodny z regułami określonymi przez test niestandardowy.

  1. W tym samym wystąpieniu programu Visual Studio Code, w którym wyświetlany jest plik azuredeploy.json, zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "tailwindLocation": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Nazwa parametru location została zmieniona na tailwindLocation. Teoretycznie ten parametr powinien teraz pomyślnie przejść test. Sprawdźmy to.

  2. Pozostań w tym samym wystąpieniu programu Visual Studio Code i uruchom polecenie Test-AzTemplate w zintegrowanym terminalu:

    Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

    Dane wyjściowe wyglądają teraz w następujący sposób:

    Validating custom\azuredeploy.json
  deploymentTemplate
    [+] Custom ParameterNaming (2 ms)

To wszystko! Zaimplementowano i uruchomiono test niestandardowy. Skorygowano również szablon wdrożenia w celu dopasowania go do warunku testu.

Tworzenie i uruchamianie testu niestandardowego

Utworzysz niestandardowy test i uruchomisz go przy użyciu zestawu narzędzi do testowania. Poprawisz również szablon wdrożenia, aby zapewnić pomyślne wykonanie testu. Test niestandardowy będzie weryfikował, czy wszystkie parametry są zgodne z regułą nazewnictwa. Ta reguła jest wymaganiem specyficznym dla dziedziny dotyczącej produktu, nad którym pracujesz Ty i Twój zespół.

Zalecamy, aby w tym ćwiczeniu mieć otwarte dwa edytory tekstu.

  • Tworzenie testu niestandardowego Znajdź ścieżkę podkatalogu arm-ttk/testcases/deploymentTemplate/ katalogu instalacyjnego zestawu narzędzi do testowania. Teraz uruchomisz program Visual Studio Code, w którym utworzysz i edytujesz test niestandardowy.
  • Tworzenie pliku szablonu i uruchamianie testów. Wybierz lokalizację dla tej ścieżki. Zaleca się uruchomienie wystąpienia programu Visual Studio Code z tej ścieżki, aby można było łatwo edytować plik azuredeploy.json po wyświetleniu monitu. Wraz z tym wystąpieniem programu Visual Studio Code uruchom zintegrowany terminal, aby ułatwić uruchamianie testów.

Tworzenie pliku szablonu

Wybierz katalog i utwórz plik o nazwie azuredeploy.json.

Ostrzeżenie

Upewnij się, że wybrany katalog jest pusty i nie ma podkatalogów

Dodaj następującą zawartość:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": []
}

Tworzenie testu niestandardowego

  1. Otwórz terminal. Przejdź do katalogu instalacyjnego zestawu narzędzi do testowania. Przejdź do podkatalogu arm-ttk/testcases/deploymentTemplate. Uruchom następujące polecenie:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  2. Utwórz plik niestandardowy o nazwie Custom-ParameterNaming.test.ps1. Wstaw do tego pliku następującą zawartość:

    param(
[Parameter(Mandatory=$false,Position=0)] #not mandatory for case of an empty resource array
[PSObject]
$MainTemplateResources
)

Write-Error "To be implemented"

    Pozostaw otwarty edytor tekstu. Będziesz edytować ten plik później.

Uruchamianie testu niestandardowego

Uruchom test niestandardowy, wykonując następujące czynności:

  1. Otwórz nowe okno terminalu lub ponownie użyj starego.

  2. Przejdź do katalogu, w którym utworzono plik azuredeploy.json. Uruchom następujące polecenie, aby uruchomić program Visual Studio Code:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog szablonów, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  3. Z poziomu programu Visual Code otwórz zintegrowany terminal, wybierając z menu głównego pozycję Terminal>Nowy terminal. Aby uruchomić powłokę programu PowerShell, uruchom w terminalu następujące polecenie:

    pwsh

    Wyświetlone dane wyjściowe będą podobne do następujących:

    PowerShell 7.0.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

  4. Uruchom polecenie Import-Module w terminalu.

    Uwaga

    Przed zaimportowaniem modułu zastąp ciąg patch/to/arm-ttk/arm-ttk.psd1 ścieżką do pobranego zestawu narzędzi do testowania.

    Import-Module path/to/arm-ttk/arm-ttk.psd1

    Napiwek

    Jeśli narzędzie zostanie pobrane lub sklonowane do katalogu Pobrane , ścieżka będzie wyglądać następująco: /Users/<user>/Downloads/arm-ttk/arm-ttk/arm-ttk.psd1.

    Teraz możesz przystąpić do korzystania z narzędzia. Dopóki jesteś w tej samej sesji programu PowerShell, nie ma potrzeby ponownego uruchamiania polecenia importowania.

  5. Uruchom polecenie Test-AzTemplate w terminalu:

    Test-AzTemplate -TemplatePath .

    Dane wyjściowe są podobne do następujących. Zwróć uwagę na wyróżnione wiersze pokazujące test:

    Validating custom\azuredeploy.json
  JSONFiles Should Be Valid
    [+] JSONFiles Should Be Valid (56 ms)
Pass  : 1
Fail  : 0
Total : 1



  adminUsername Should Not Be A Literal
    [+] adminUsername Should Not Be A Literal (68 ms)
  apiVersions Should Be Recent In Reference Functions
    [+] apiVersions Should Be Recent In Reference Functions (203 ms)
  apiVersions Should Be Recent
    [+] apiVersions Should Be Recent (137 ms)
  artifacts parameter
    [+] artifacts parameter (145 ms)
  CommandToExecute Must Use ProtectedSettings For Secrets
    [+] CommandToExecute Must Use ProtectedSettings For Secrets (171 ms)
  deploymentTemplate
    [-] Custom ParameterNaming (354 ms)
        To be implemented

  DependsOn Best Practices
    [+] DependsOn Best Practices (152 ms)
  Deployment Resources Must Not Be Debug
    [+] Deployment Resources Must Not Be Debug (152 ms)
  DeploymentTemplate Must Not Contain Hardcoded Uri
    [+] DeploymentTemplate Must Not Contain Hardcoded Uri (185 ms)
  DeploymentTemplate Schema Is Correct
    [+] DeploymentTemplate Schema Is Correct (197 ms)
  Dynamic Variable References Should Not Use Concat
    [+] Dynamic Variable References Should Not Use Concat (157 ms)
  IDs Should Be Derived From ResourceIDs
    [+] IDs Should Be Derived From ResourceIDs (69 ms)
  Location Should Not Be Hardcoded
    [+] Location Should Not Be Hardcoded (260 ms)
  ManagedIdentityExtension must not be used
    [+] ManagedIdentityExtension must not be used (70 ms)
  Min And Max Value Are Numbers
    [+] Min And Max Value Are Numbers (213 ms)
  Outputs Must Not Contain Secrets
    [+] Outputs Must Not Contain Secrets (76 ms)
  Parameter Types Should Be Consistent
    [+] Parameter Types Should Be Consistent (68 ms)
  Parameters Must Be Referenced
    [+] Parameters Must Be Referenced (93 ms)
  Password params must be secure
    [+] Password params must be secure (111 ms)
  providers apiVersions Is Not Permitted
    [+] providers apiVersions Is Not Permitted (68 ms)
  ResourceIds should not contain
    [+] ResourceIds should not contain (210 ms)
  Resources Should Have Location
    [+] Resources Should Have Location (113 ms)
  Resources Should Not Be Ambiguous
    [+] Resources Should Not Be Ambiguous (147 ms)
  Secure Params In Nested Deployments
    [+] Secure Params In Nested Deployments (242 ms)
  Secure String Parameters Cannot Have Default
    [+] Secure String Parameters Cannot Have Default (129 ms)
  Template Should Not Contain Blanks
    [+] Template Should Not Contain Blanks (201 ms)
  URIs Should Be Properly Constructed
    [+] URIs Should Be Properly Constructed (180 ms)
  Variables Must Be Referenced
    [+] Variables Must Be Referenced (132 ms)
  Virtual Machines Should Not Be Preview
    [+] Virtual Machines Should Not Be Preview (91 ms)
  VM Images Should Use Latest Version
    [+] VM Images Should Use Latest Version (114 ms)
  VM Size Should Be A Parameter
    [+] VM Size Should Be A Parameter (130 ms)
Pass  : 31
Fail  : 1
Total : 32

    Po znalezieniu testu pozostaw to okno terminalu otwarte. Użyjesz go później.

Refaktoryzacja testu niestandardowego

Teraz nadasz testowi niestandardowemu prawidłową implementację.

  1. Wróć do edytora tekstu z plikiem Custom-ParameterNaming.test.ps1.

    Uwaga

    Jeśli przypadkowo zamknięto program Visual Studio Code, przejdź do podkatalogu arm-ttk/testcases/deploymentTemplate i otwórz plik Custom-ParameterNaming.test.ps1.

  2. Zastąp zawartość pliku następującym kodem:

    <#
.Synopsis
 Ensures that all parameters adheres to a naming standard
.Description
 All parameters should start with the company specific prefix 'tailwind'
#>
param(
   # The Template Object
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateObject,

   # The Template JSON Text
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateText
)

foreach ($parameter in $TemplateObject.parameters.psobject.properties) {
  # If the parameter name starts with tailwind, then the parameter is correctly named
  if ($parameter.Name -notmatch 'tailwind*') {
     Write-Error "Parameter '$($parameter.Name)' must start with prefix 'tailwind'" -TargetObject $parameter
  }
}

    Powyższy kod wykonuje iterację po wszystkich parametrach. Sprawdza atrybut name i sprawdza, czy nazwa zaczyna się od prefiksu tailwind. Jeśli sprawdzony parametr nie jest zgodny z regułą nazewnictwa, kod wywołuje Write-Error polecenie cmdlet z odpowiednim komunikatem o błędzie.

Aktualizowanie pliku szablonu

Teraz dodasz parametr do pliku szablonu.

  1. Wybierz edytor tekstu z plikiem azuredeploy.json i zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Poprzednia zawartość szablonu definiuje parametr o nazwie location , który nie spełnia reguły nazewnictwa, ponieważ nie ma prefiksu tailwind .

Ponowne uruchamianie zestawu narzędzi testowych

Masz teraz napisany test niestandardowy. Jednak nazewnictwo pliku szablonu nie spełnia wymagania. W związku z tym oczekujesz, że przebieg testu zakończy się niepowodzeniem. Upewnij się, że tak jest, wykonując następujący krok.

Uwaga

Użyj istniejącego okna zintegrowanego terminalu programu Visual Studio Code, w którym uruchomiono program PowerShell i zaimportowano zestaw narzędzi testowych.

W programie Visual Studio Code uruchom polecenie Test-AzTemplate w zintegrowanym terminalu.

Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

Poprzednie polecenie jest uruchamiane z parametrem o nazwie -Test, który przyjmuje nazwę testu jako dane wejściowe. Custom-ParameterNaming Podano jako parametr, co oznacza, że zostanie uruchomiony tylko nowo utworzony test.

Napiwek

Używanie tego parametru jest dobrym rozwiązaniem podczas opracowywania testu, ponieważ ogranicza on uruchamiane elementy i rozmiar danych wyjściowych terminalu.

Wynikiem tego polecenia są następujące dane wyjściowe:

Validating custom\azuredeploy.json
 deploymentTemplate
   [-] Custom ParameterNaming (2ms)
       Parameter 'location' must start with prefix 'tailwind'

Wynik wskazuje, że test działa. Upewnijmy się, że tak jest, zmieniając plik wdrożenia.

Poprawianie pliku szablonu

Teraz chcesz sprawdzić poprawność testu niestandardowego, zmieniając plik szablonu tak, aby był zgodny z regułami określonymi przez test niestandardowy.

  1. W tym samym wystąpieniu programu Visual Studio Code, w którym wyświetlany jest plik azuredeploy.json, zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "tailwindLocation": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Nazwa parametru location została zmieniona na tailwindLocation. Teoretycznie ten parametr powinien teraz pomyślnie przejść test. Sprawdźmy to.

  2. Pozostań w tym samym wystąpieniu programu Visual Studio Code i uruchom polecenie Test-AzTemplate w zintegrowanym terminalu:

    Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

    Dane wyjściowe wyglądają teraz w następujący sposób:

    Validating custom\azuredeploy.json
  deploymentTemplate
    [+] Custom ParameterNaming (2 ms)

To wszystko! Zaimplementowano i uruchomiono test niestandardowy. Skorygowano również szablon wdrożenia w celu dopasowania go do warunku testu.

Tworzenie i uruchamianie testu niestandardowego

Utworzysz niestandardowy test i uruchomisz go przy użyciu zestawu narzędzi do testowania. Poprawisz również szablon wdrożenia, aby zapewnić pomyślne wykonanie testu. Test niestandardowy będzie weryfikował, czy wszystkie parametry są zgodne z regułą nazewnictwa. Ta reguła jest wymaganiem specyficznym dla dziedziny dotyczącej produktu, nad którym pracujesz Ty i Twój zespół.

Zalecamy, aby w tym ćwiczeniu mieć otwarte dwa edytory tekstu.

  • Tworzenie testu niestandardowego Znajdź ścieżkę podkatalogu arm-ttk\testcases\deploymentTemplate\ katalogu instalacyjnego zestawu narzędzi testowych. Teraz uruchomisz program Visual Studio Code, w którym utworzysz i edytujesz test niestandardowy.
  • Tworzenie pliku szablonu i uruchamianie testów. Wybierz lokalizację dla tej ścieżki. Zaleca się uruchomienie wystąpienia programu Visual Studio Code z tej ścieżki, aby można było łatwo edytować plik azuredeploy.json po wyświetleniu monitu. Wraz z tym wystąpieniem programu Visual Studio Code uruchom zintegrowany terminal, aby ułatwić uruchamianie testów.

Tworzenie pliku szablonu

Wybierz katalog i utwórz plik o nazwie azuredeploy.json.

Ostrzeżenie

Upewnij się, że wybrany katalog jest pusty i nie ma podkatalogów

Dodaj następującą zawartość:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": []
}

Tworzenie testu niestandardowego

  1. Otwórz terminal.

  2. Przejdź do katalogu instalacyjnego zestawu narzędzi do testowania.

  3. Umieść się w podkatalogu arm-ttk\testcases\deploymentTemplate.

  4. Uruchom następujące polecenie:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  5. Utwórz plik Custom-ParameterNaming.test.ps1 i nadaj mu następującą zawartość:

    param(
[Parameter(Mandatory=$false,Position=0)] #not mandatory for case of an empty resource array
[PSObject]
$MainTemplateResources
)

Write-Error "To be implemented"

    Pozostaw otwarty edytor tekstu. Będziesz edytować ten plik później.

Uruchamianie testu niestandardowego

Uruchom test niestandardowy, wykonując następujące czynności:

  1. Otwórz nowe okno terminalu lub ponownie użyj starego.

  2. Przejdź do katalogu, w którym utworzono plik azuredeploy.json.

  3. Uruchom następujące polecenie, aby uruchomić program Visual Studio Code:

    code .

    Uwaga

    Otwórz program Visual Studio Code ręcznie i otwórz katalog szablonów, jeśli program Visual Studio Code nie znajduje się w ścieżce.

  4. W programie Visual Studio Code otwórz zintegrowany terminal. Wywołaj paletę poleceń, wpisz PowerShell i wybierz pozycję Pokaż zintegrowany terminal.

  5. W terminalu uruchom następujące polecenie:

    Uwaga

    Przed zaimportowaniem modułu zastąp ciąg path/to/arm-ttk/arm-ttk.psd1 ścieżką do pobranego zestawu narzędzi do testowania.

    Import-Module path\to\arm-ttk\arm-ttk.psd1

    Napiwek

    Jeśli narzędzie zostanie pobrane lub sklonowane do katalogu Pobrane , ścieżka będzie wyglądać następująco: C:\Users\<user>\Downloads\arm-ttk\arm-ttk\arm-ttk\arm-ttk.psd1.

    Teraz możesz przystąpić do korzystania z narzędzia. Dopóki jesteś w tej samej sesji programu PowerShell, nie ma potrzeby ponownego uruchamiania polecenia importowania.

  6. Uruchom polecenie Test-AzTemplate w terminalu:

    Test-AzTemplate -TemplatePath .

    Dane wyjściowe są podobne do następujących. Zwróć uwagę na wyróżnione wiersze pokazujące test:

    Validating custom\azuredeploy.json
  JSONFiles Should Be Valid
    [+] JSONFiles Should Be Valid (56 ms)
Pass  : 1
Fail  : 0
Total : 1



  adminUsername Should Not Be A Literal
    [+] adminUsername Should Not Be A Literal (68 ms)
  apiVersions Should Be Recent In Reference Functions
    [+] apiVersions Should Be Recent In Reference Functions (203 ms)
  apiVersions Should Be Recent
    [+] apiVersions Should Be Recent (137 ms)
  artifacts parameter
    [+] artifacts parameter (145 ms)
  CommandToExecute Must Use ProtectedSettings For Secrets
    [+] CommandToExecute Must Use ProtectedSettings For Secrets (171 ms)
  deploymentTemplate
    [-] Custom ParameterNaming (354 ms)
        To be implemented

  DependsOn Best Practices
    [+] DependsOn Best Practices (152 ms)
  Deployment Resources Must Not Be Debug
    [+] Deployment Resources Must Not Be Debug (152 ms)
  DeploymentTemplate Must Not Contain Hardcoded Uri
    [+] DeploymentTemplate Must Not Contain Hardcoded Uri (185 ms)
  DeploymentTemplate Schema Is Correct
    [+] DeploymentTemplate Schema Is Correct (197 ms)
  Dynamic Variable References Should Not Use Concat
    [+] Dynamic Variable References Should Not Use Concat (157 ms)
  IDs Should Be Derived From ResourceIDs
    [+] IDs Should Be Derived From ResourceIDs (69 ms)
  Location Should Not Be Hardcoded
    [+] Location Should Not Be Hardcoded (260 ms)
  ManagedIdentityExtension must not be used
    [+] ManagedIdentityExtension must not be used (70 ms)
  Min And Max Value Are Numbers
    [+] Min And Max Value Are Numbers (213 ms)
  Outputs Must Not Contain Secrets
    [+] Outputs Must Not Contain Secrets (76 ms)
  Parameter Types Should Be Consistent
    [+] Parameter Types Should Be Consistent (68 ms)
  Parameters Must Be Referenced
    [+] Parameters Must Be Referenced (93 ms)
  Password params must be secure
    [+] Password params must be secure (111 ms)
  providers apiVersions Is Not Permitted
    [+] providers apiVersions Is Not Permitted (68 ms)
  ResourceIds should not contain
    [+] ResourceIds should not contain (210 ms)
  Resources Should Have Location
    [+] Resources Should Have Location (113 ms)
  Resources Should Not Be Ambiguous
    [+] Resources Should Not Be Ambiguous (147 ms)
  Secure Params In Nested Deployments
    [+] Secure Params In Nested Deployments (242 ms)
  Secure String Parameters Cannot Have Default
    [+] Secure String Parameters Cannot Have Default (129 ms)
  Template Should Not Contain Blanks
    [+] Template Should Not Contain Blanks (201 ms)
  URIs Should Be Properly Constructed
    [+] URIs Should Be Properly Constructed (180 ms)
  Variables Must Be Referenced
    [+] Variables Must Be Referenced (132 ms)
  Virtual Machines Should Not Be Preview
    [+] Virtual Machines Should Not Be Preview (91 ms)
  VM Images Should Use Latest Version
    [+] VM Images Should Use Latest Version (114 ms)
  VM Size Should Be A Parameter
    [+] VM Size Should Be A Parameter (130 ms)
Pass  : 31
Fail  : 1
Total : 32

    Po znalezieniu testu pozostaw to okno terminalu otwarte. Użyjesz go później.

Refaktoryzacja testu niestandardowego

Teraz nadasz testowi niestandardowemu prawidłową implementację.

  1. Wróć do edytora tekstu z plikiem Custom-ParameterNaming.test.ps1.

    Uwaga

    Jeśli przypadkowo zamknięto program Visual Studio Code, przejdź do podkatalogu testcases/deploymentTemplate i otwórz plik Custom-ParameterNaming.test.ps1.

  2. Zastąp zawartość pliku następującym kodem:

    <#
.Synopsis
 Ensures that all parameters adheres to a naming standard
.Description
 All parameters should start with the company specific prefix 'tailwind'
#>
param(
   # The Template Object
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateObject,

   # The Template JSON Text
   [Parameter(Mandatory = $true, Position = 0)]
   [PSObject]
   $TemplateText
)

foreach ($parameter in $TemplateObject.parameters.psobject.properties) {
  # If the parameter name starts with tailwind, then the parameter is correctly named
  if ($parameter.Name -notmatch 'tailwind*') {
     Write-Error "Parameter '$($parameter.Name)' must start with prefix 'tailwind'" -TargetObject $parameter
  }
}

    Powyższy kod wykonuje iterację po wszystkich parametrach. Sprawdza atrybut name i sprawdza, czy nazwa zaczyna się od prefiksu tailwind. Jeśli sprawdzony parametr nie jest zgodny z regułą nazewnictwa, kod wywołuje Write-Error polecenie cmdlet z odpowiednim komunikatem o błędzie.

Aktualizowanie pliku szablonu

Teraz dodasz parametr do pliku szablonu.

  1. Wybierz edytor tekstu z plikiem azuredeploy.json i zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Poprzednia zawartość szablonu definiuje parametr o nazwie location , który nie spełnia reguły nazewnictwa, ponieważ nie ma prefiksu tailwind .

Ponowne uruchamianie zestawu narzędzi testowych

Masz teraz napisany test niestandardowy. Jednak nazewnictwo pliku szablonu nie spełnia wymagania. W związku z tym oczekujesz, że przebieg testu zakończy się niepowodzeniem. Upewnij się, że tak jest, wykonując następujący krok.

Użyj istniejącego okna zintegrowanego terminalu programu Visual Studio Code, w którym uruchomiono program PowerShell i zaimportowano zestaw narzędzi testowych.

W programie Visual Studio Code uruchom polecenie Test-AzTemplate w zintegrowanym terminalu.

Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

Poprzednie polecenie jest uruchamiane z parametrem -Test, który przyjmuje nazwę testu jako dane wejściowe. Custom-ParameterNaming Podano jako parametr, co oznacza, że zostanie uruchomiony tylko nowo utworzony test.

Napiwek

Używanie tego parametru jest dobrym rozwiązaniem podczas opracowywania testu, ponieważ ogranicza on uruchamiane elementy i rozmiar danych wyjściowych terminalu.

Wynikiem tego polecenia są następujące dane wyjściowe:

Validating custom\azuredeploy.json
 deploymentTemplate
   [-] Custom ParameterNaming (2ms)
       Parameter 'location' must start with prefix 'tailwind'

Wynik wskazuje, że test działa. Upewnijmy się, że tak jest, zmieniając plik wdrożenia.

Poprawianie pliku szablonu

Teraz chcesz sprawdzić poprawność testu niestandardowego, zmieniając plik szablonu tak, aby był zgodny z regułami określonymi przez test niestandardowy.

  1. W tym samym wystąpieniu programu Visual Studio Code, w którym wyświetlany jest plik azuredeploy.json, zmień zawartość pliku na następującą zawartość:

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "tailwindLocation": {
      "type": "string",
      "metadata": {
        "description": "a deployment location"
      }
    }
  },
  "resources": []
}

    Nazwa parametru location została zmieniona na tailwindLocation. Teoretycznie ten parametr powinien teraz pomyślnie przejść test. Sprawdźmy to.

  2. Pozostań w tym samym wystąpieniu programu Visual Studio Code i uruchom polecenie Test-AzTemplate w zintegrowanym terminalu:

    Test-AzTemplate -TemplatePath . -Test Custom-ParameterNaming

    Dane wyjściowe wyglądają teraz w następujący sposób:

    Validating custom\azuredeploy.json
  Custom ParameterNaming
    [+] Custom ParameterNaming (9 ms)

To wszystko! Zaimplementowano i uruchomiono test niestandardowy. Skorygowano również szablon wdrożenia w celu dopasowania go do warunku testu.