Power Apps Test Engine YAML format (підготовча версія)

Нотатка

Підготовчі функції призначені для невиробничого використання і можуть бути обмежені. Ці функції доступні до офіційного випуску, щоб клієнти могли ознайомитися з ними заздалегідь і залишити відгуки.

Тести визначаються в YAML, дотримуючись тих самих рекомендацій, що й Power Fx. Дізнайтеся більше про граматику формули Power Fx YAML.

Докладні приклади див. в папці PowerApps-TestEngine/samples .

Визначення схем YAML

Власність	Опис
testSuite	Визначає один тестовий пакет, тестові випадки в тестовому програмному комплексі та конфігурацію, специфічні для тестового програмного комплексу
testSettings	Визначає параметри тестового програмного комплексу, які повторно використовуються в кількох тестових випадках
відхилення середовища	Визначає змінні, які потенційно можуть змінюватися під час перенесення програми в різних середовищах

testSuite

Використовується для визначення одного тесту.

Власність	Тип	Опис
persona	рядок	Обов’язково. Користувач, який увійшов, щоб виконати перевірку. Має відповідати особі, указаній у розділі Користувачі .
testCases	Тестові регістри	Обов’язково. Визначає тестові випадки в тестовому комплексі. Тестові випадки, що містяться в тестових комплексах, виконуються послідовно. Стан програми зберігається в усіх тестових випадках у програмному комплексі.
testSuiteName	рядок	Обов’язково. Ім'я тестового програмного комплексу.
appLogicalName	рядок	Необов'язково. Логічне ім'я програми, яку потрібно запустити. Його можна отримати з рішення. Для програм із полотном потрібно додати його до рішення, щоб отримати його. Див . статтю Визначення програми в тестовому плані
appId	GUID	Необов'язково. Ідентифікатор програми, яку потрібно запустити. Обов'язковий і використовується, лише якщо appLogicalName його немає. Ідентифікатор програми слід використовувати лише для програм із полотном, яких немає в рішенні. Див . статтю Визначення програми в тестовому плані
networkRequestMocks	NetworkRequestMocks	Необов'язково. Визначає макети мережевих запитів, необхідні для перевірки.
onTestCaseComplete	рядок	Необов'язково. Визначає кроки, які потрібно спрацьовувати для кожного тестового інциденту в програмному комплексі після завершення виконання інциденту.
onTestCaseStart	рядок	Необов'язково. Визначає кроки, які потрібно спрацьовувати для кожного тестового інциденту в програмному комплексі до початку виконання інциденту.
onTestSuiteComplete	рядок	Необов'язково. Визначає кроки, які потрібно спрацьовувати після завершення виконання програмного комплексу.
testSuiteDescription	рядок	Необов'язково. Додаткові відомості описують призначення тестового програмного комплексу.

Визначення програми в тестовому плані

Вам потрібно встановити appLogicalName або appId визначити свою програму. Те, що ви використовуєте, залежить від того, чи програма визначається в рішенні.

Програми на основі рішень (рекомендовано)

Коли ви визначаєте програми в рішеннях, тести залишаються портативними в середовищах. Установіть властивість appLogicalName , яка вказує на те, що програма базується на рішенні.

Щоб знайти логічне ім'я програми:

1. Відкриття рішення, що містить програму, у програмі Power Apps
2. Використовуйте ім'я (не коротке ім'я) у списку. Значення імені містить префікс настроювання видавця рішення.

Автономні програми

Якщо програму не визначено в рішенні, потрібно скористатися властивістю appId .

Щоб знайти ідентифікатор програми, виконайте наведені нижче дії.

1. Пошук програми в списку Power Apps
2. Відкрити відомості та занотуйте GUID ідентифікатора програми

NetworkRequestMocks

Власність	Тип	Опис
requestURL	рядок	Обов’язково. URL-адреса запиту, яка отримує глузливу відповідь. Приймаються візерунки ковзних об'єктів
responseDataFile	рядок	Обов’язково. Текстовий файл із глузливим вмістом відповіді. Увесь текст у цьому файлі читається як відповідь
headers	масив	Необов'язково. Список полів заголовків у запиті у форматі [ім'я_поля: полеValue]
method	рядок	Необов'язково. Метод запиту (GET, POST тощо)
requestBodyFile	рядок	Необов'язково. Текстовий файл із тілом запиту. Увесь текст у цьому файлі читається як основний текст запиту

Для необов'язкових властивостей, якщо значення не вказано, маршрутизація застосовується до всіх. Наприклад, якщо method аргумент має null-значення, ми повертаємо відповідь, яка б метод не відповідала іншим властивостям.

Для програм requestURLmethod Sharepoint/Dataverse/Connector вони можуть бути однаковими для всіх запитів. x-ms-request-method і x-ms-request-url в заголовках може знадобитися настроїти в цьому випадку, щоб визначити різні запити.

Тестові регістри

Власність	Тип	Опис
testCaseName	рядок	Обов’язково. Ім'я тестового інциденту, який використовується для звітування про успішність і невдачу
testSteps	Тестові позначки	Обов’язково. Набір функцій Power Fx, які описують кроки, необхідні для виконання тестового інциденту. Див . приклад TestSteps
testCaseDescription	No	Необов'язково. Додаткові відомості описують, що робить тестовий інцидент

Тестові позначки

• TestSteps може використовувати будь-які наявні функції Power Fx для тестового обробника або певні тестові функції , визначені в цій структурі.
• Значення має починатися з символу каналу (|), щоб дозволити багаторядкові вирази YAML, а потім знак рівності (=), щоб указати, що це вираз Power Fx
• Функції слід розділяти крапкою з комою (;).
• Примітки можна використовувати й починати з подвійних символів зворотної скісних рисок (//).

Приклад testSteps

testCases:
   - testCaseName: Fill in a city name and do the search
   testSteps: |
      = Screenshot("connectorapp_loaded.png");
         SetProperty(TextInput1.Text, "Atlanta");
         Select(Button1);
         Assert(Label4.Text = "You are seeing the mock response", "Validate the output is from the mock");
         Screenshot("connectorapp_end.png");

testSettings

Використовується для визначення параметрів тестів у тестовому плані.

Власність	Тип	Опис
browserConfigurations	Конфігурація браузера[]	Обов’язково. Список конфігурацій браузера, які потрібно перевірити. Потрібно вказати принаймні один браузер.
extensionModules	extensionModules	Необов'язково. Містить дані про розширення для ввімкнення.
filePath	рядок	Необов'язково. Шлях до окремого файлу yaml з усіма параметрами перевірки. За умови, він перевизначить всі параметри перевірки в тестовому плані.
headless	boolean	Необов'язково. Значення за замовчуванням – істина. Якщо встановлено значення false, браузер відображається під час тестового виконання.
locale	рядок	Необов'язково. Синтаксис мови або культури, у якому записуються тестові або тестові кроки. Якщо не вказано, CultureInfo.CurrentCulture використовується для локалізації за замовчуванням для аналізу етапів перевірки. Див . статтю Зауваження щодо регіону та мови
recordVideo	boolean	Необов'язково. Значення за замовчуванням — false. Якщо встановлено значення true, запис відео перевірки записується.
timeout	Ціле число	Необов'язково. Значення часу очікування в мілісекундах. За замовчуванням 30 000 мілісекунд (30s). Якщо будь-яка операція займає більше часу очікування, вона завершує перевірку через помилку.
powerFxTestTypes	name value пара	Необов'язково. Список імен типів і визначень типів Power Fx. Приклад powerFxTestTypes
testFunctions	description code пара	Необов'язково. Список описів і визначень функцій Power Fx. Приклад функції testFunctions

extensionModules

Містить дані про розширення для ввімкнення.

Власність	Тип	Опис
enable	логічний	Чи ввімкнуто модулі розширення.
allowPowerFxNamespaces	список	Список просторів імен PowerFx, які потрібно ввімкнути.
parameters	пари ключових значень	Властивості зі значеннями для керування модулями розширення. Наразі для цього є лише логічний enableDataverseFunctions параметр.

У цьому прикладі показано, як увімкнути простір імен PowerFx Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

Докладніше про функції попереднього перегляду

Зауваження щодо регіону та мови

Test Engine підтримує різні мовні та регіональні параметри, як-от десяткові та роздільники списків. Ця testSettings.locale властивість керує такою поведінкою. Докладні відомості див. в статті Глобальна підтримка в Microsoft Power Fx.

Перегляньте ці зразки конфігурацій у сховищіPowerApps-TestEngine GitHub:

• Для регіонів, які використовують крапку з комою як роздільники списків
• Для областей, які використовують коми як десяткові роздільники

PowerFxTestTypes example

powerFxTestTypes:
 - name: ControlName
   value: |
      {ControlName: Text} 
 - name: Options
   value: |
      [{Name: Text, Value: Number}]   

У цьому прикладі показано, як визначити настроювані типи Power Fx для використання в тестових випадках. Тип ControlName визначається як запис з одним Text полем, а Options тип визначається як таблиця записів, кожна з яких містить Name поле типу Text та Value поле типу Number. Настроювані типи можна використовувати для створення складніших і конкретних сценаріїв перевірки, що підвищує гнучкість і потужність визначень тесту.

приклад testFunctions

testFunctions:
 - description: Wait until control is visible using Document Object Model (DOM) selector
   code: |
    WaitUntilVisible(control: Text): Void = 
      Preview.PlaywrightAction(Concatenate("//div[@data-id='", control, "']"), "wait");
 - description: Get the options for a control using Power Fx control from Model Driven App (MDA)
   code: |
    GetOptions(control: ControlName): Options =
      Preview.GetOptions(control);

У прикладах цих тестових функцій показано, як визначити спеціальні функції Power Fx для використання в тестових випадках. Функція WaitUntilVisible використовує селектор DOM, щоб зачекати, доки не буде видно вказаний елемент керування, використовуючи дії Драматурга. Функція GetOptions отримує параметри для вказаного елемента керування з програми MDA на основі моделі , використовуючи елемент керування Power Fx. Ці спеціальні функції підвищують гнучкість і потужність визначень тестів, що дає змогу використовувати складніші та конкретні сценарії тестування.

Конфігурація браузера

Для кожної перевіркинастройки потрібен принаймні один BrowserConfiguration.

Власність	Тип	Опис
browser	рядок	Обов’язково. Браузер, який буде запущено під час тестування. Має відповідати браузерам, що підтримуються драматургом.
device	рядок	Необов'язково. Пристрій для емуляції під час запуску браузера. Має відповідати пристроям, які підтримує драматург
screenHeight	Ціле число	Необов'язково. Висота екрана, яка використовується під час запуску браузера. Якщо вказано, screenWidth слід також указати значення.
screenWidth	Ціле число	Необов'язково. Ширина екрана, яка використовується під час запуску браузера. Якщо вказано, screenHeight слід також указати значення.

відхилення середовища

Ви можете зберігати значення різних типів як екологічні значення, але найпоширенішим випадком є зберігання відомостей про облікові дані зі списком користувачів.

Користувачів

Щоб переконатися, що облікові дані зберігаються безпечно, визначення перевірки посилається на користувачів, які personaNameвикористовують . Зберігання облікових даних у файлах тестового плану не підтримується.

Приклад:

environmentVariables:
    - users:
        - personaName: "User1"
          emailKey: "user1Email"
        - personaName: "User2"
          emailKey: "user2Email"

personaName Використовується як частина визначення перевірки, щоб указати, як користувачу виконати перевірку.

Підтримувані механізми зберігання облікових даних

Щоб зберегти облікові дані як змінні середовища, можна встановити їх таким йому:

# In PowerShell - replace variableName and variableValue with the correct values
$env:variableName = "variableValue"

У YAML потрібно визначити дві властивості, які вказують на те, що облікові дані цього користувача зберігаються в змінних середовища:

• emailKey: змінна середовища, яка використовується для зберігання електронної пошти користувача.

Приклад YAML:

    - personaName: "User1"
      emailKey: "user1Email"

Приклад PowerShell для настроювання облікових даних користувача на основі YAML:

$env:user1Email = "someone@example.com"

Див. також

Огляд тестового обробника Power Apps (підготовча версія)
Power Apps Функції тестового двигуна Power Fx (попередній перегляд)