Power Apps Test Engine-YAML-Format (Vorschauversion)

Artikel
03/07/2024

[Dieses Thema ist Teil der Dokumentation zur Vorabversion und kann geändert werden.]

Tests werden in YAML nach denselben Richtlinien definiert wie bei Power Fx. Erfahren Sie mehr über die Power Fx-YAML-Formelgrammatik.

Ausführliche Beispiele finden Sie im Ordner PowerApps-TestEngine/Beispiele.

YAML-Schemadefinition

Eigenschaften	Eigenschaft
testSuite	Definiert eine Testsuite, die Testfälle in der Testsuite und die für die Testsuite spezifische Konfiguration
testSettings	Definiert Einstellungen für die Testsuite, die in mehreren Testfällen wiederverwendet werden
environmentVariables	Definiert Variablen, die sich möglicherweise ändern können, wenn die App in verschiedene Umgebungen portiert wird

testSuite

Wird zum Definieren eines Tests verwendet.

Test-YAML-Schemadefinition

Eigenschaften	Erforderlich	Beschreibung
`testSuiteName`	Ja	Der Name der Testsuite
`testSuiteDescription`	Nein	Zusätzliche Informationen zum Beschreiben der Funktion der Testsuite
`persona`	Ja	Der Benutzende, der angemeldet ist, um den Test durchzuführen. Muss mit einer im Abschnitt Benutzer aufgeführten Persona übereinstimmen
`appLogicalName`	Ja	Der logische Name der App, die eingeführt werden soll. Sie kann aus der Lösung gewonnen werden. Für Canvas-Apps müssen Sie sie einer Lösung hinzufügen, um sie zu erhalten
`appId`	Nein	Die ID der App, die eingeführt werden soll. Erforderlich und nur verwendet, wenn der logische App-Name nicht vorhanden ist. Die App-ID sollte nur für Canvas-Apps verwendet werden, die nicht in der Lösung enthalten sind
`networkRequestMocks`	Nein	Definiert Netzwerkanforderungs-Pseudodaten, die für den Test benötigt werden
`testCases`	Ja	Definiert Testfälle in der Testsuite. In Testsammlungen enthaltene Testfälle werden sequenziell ausgeführt. Der App-Status wird für alle Testfälle in einer Suite beibehalten
`onTestCaseStart`	Nein	Definiert die Schritte, die für jeden Testfall in einer Testsuite ausgelöst werden müssen, bevor die Ausführung des Falls beginnt
`onTestCaseComplete`	Nein	Definiert die Schritte, die für jeden Testfall in einer Testsuite ausgelöst werden müssen, nachdem die Ausführung des Falls abgeschlossen ist
`onTestSuiteComplete`	Nein	Definiert die Schritte, die ausgelöst werden müssen, nachdem die Ausführung durch die Suite abgeschlossen ist

NetworkRequestMocks testen

Eigenschaften	Erforderlich	Beschreibung
`requestURL`	Ja	Die Anforderungs-URL, die eine Simulationsantwort erhält. Globale Muster werden akzeptiert
`responseDataFile`	Ja	Eine Textdatei mit dem Inhalt der Simulationsantwort. Der gesamte Text in dieser Datei wird als Antwort gelesen
`method`	Nein	Die Anforderungsmethode (GET, POST, usw.)
`headers`	Nein	Eine Liste der Kopfzeilenfelder in der Anforderung im Format [fieldName: fieldValue]
`requestBodyFile`	Nein	Eine Textdatei mit dem Anforderungstext. Der gesamte Text in dieser Datei wird als Anforderungstext gelesen

Wenn für optionale Eigenschaften kein Wert angegeben wird, gilt das Routing für alle. Zum Beispiel, wenn method Null ist, senden wir die Simulationsantwort unabhängig von der Methode zurück, solange alle anderen Eigenschaften übereinstimmen.

Bei Sharepoint/Dataverse/Konnektor-Apps können requestURL und method für alle Anforderungen gleich sein. x-ms-request-method und x-ms-request-url in Kopfzeilen müssen in diesem Fall möglicherweise konfiguriert werden, um unterschiedliche Anforderungen zu identifizieren.

TestCases testen

Eigenschaften	Erforderlich	Eigenschaft
`testCaseName`	Ja	Der Name des Testfalls, der für die Erfolgs- und Fehlermeldung verwendet wird
`testCaseDescription`	Nein	Zusätzliche Informationen zum Beschreiben der Funktion des Testfalls
`testSteps`	Ja	Eine Reihe von Power Fx-Funktionen, die die zur Durchführung des Testfalls erforderlichen Schritte beschreiben

TestSteps testen

Hierzu können alle vorhandenen Test Engine Power Fx-Funktionen oder spezifischen Testfunktionen verwendet werden, die durch dieses Framework definiert werden.
Dies sollte mit einem | beginnen, um mehrzeilige YAML-Ausdrücke gefolgt von einem =-Zeichen zu ermöglichen, um anzuzeigen, dass es sich um einen Power Fx-Ausdruck handelt
Funktionen sollten durch ein ; getrennt werden
Kommentare können verwendet werden und sollten mit // beginnen

testSettings

Wird verwendet, um Einstellungen für die Tests im Testplan zu definieren.

testSettings-YAML-Schemadefinition

Eigenschaften	Erforderlich	Beschreibung
`locale`	Ja	Die Gebietsschema-/Kultursyntax, in der die Testfälle oder Testschritte geschrieben sind. Weitere Informationen erhalten Sie unter Globaler Support in Microsoft Power Fx. Falls nicht angegeben, wird `CultureInfo.CurrentCulture` standardmäßig für das Gebietsschema zum Parsen der Testschritte verwendet.
`browserConfigurations`	Ja	Eine Liste der zu testenden Browserkonfigurationen. Es muss mindestens ein Browser angegeben sein.
`recordVideo`	Nein	Standardwert ist „falsch“. Bei „true“ wird eine Videoaufzeichnung des Tests erfasst.
`headless`	Nein	Der Standardwert ist korrekt. Wenn der Wert auf „false“ gesetzt ist, wird der Browser während der Testausführung angezeigt.
`timeout`	Nein	Timeout-Wert in Millisekunden. Der Standardwert beträgt 30.000 Millisekunden (30 Sekunden). Wenn ein Vorgang länger dauert als das Timeout-Limit, wird der Test mit einem Fehler beendet.
`filePath`	Nein	Der Dateipfad zu einer separaten Yaml-Datei mit allen Testeinstellungen. Falls angegeben, werden alle Testeinstellungen im Testplan überschrieben.

testSettings-Browserkonfiguration

Eigenschaften	Erforderlich	Beschreibung
`browser`	Ja	Der Browser, der beim Testen gestartet werden soll. Sollte mit den von Playwright unterstützten Browsern übereinstimmen.
`device`	Nein	Das Gerät, das beim Starten des Browsers emuliert werden soll. Sollte mit den von Playwright unterstützten Geräten übereinstimmen
`screenHeight`	Nein	Die Höhe der Anzeige, die beim Starten des Browsers verwendet werden soll. Falls angegeben, muss auch `screenWidth` angegeben werden.
`screenWidth`	Nein	Die Breite der Anzeige, die beim Starten des Browsers verwendet werden soll. Falls angegeben, muss auch `screenHeight` angegeben werden.

Users

Um sicherzustellen, dass Anmeldeinformationen sicher gespeichert werden, verweist die Testdefinition mithilfe eines Persona-Namens auf Benutzende. Das Speichern von Anmeldeinformationen in Testplandateien wird nicht unterstützt.

Verweise auf die Benutzeranmeldeinformationen finden Sie im Abschnitt environmentVariables als Liste von users

Beispiel:

environmentVariables:
    - users:
        - personaName: "User1"
          emailKey: "user1Email"
          passwordKey: "user1Password"
        - personaName: "User2"
          emailKey: "user2Email"
          passwordKey: "user2Password"

Der personaName wird als Teil der Testdefinition verwendet, um anzugeben, unter welchem Benutzenden der Test ausgeführt werden soll.

Unterstützte Speichermechanismen für Anmeldeinformationen

Hinweis

Die Multi-Faktor-Authentifizierung wird nicht unterstützt.

Umgebungsvariablen

Um Anmeldeinformationen als Umgebungsvariablen zu speichern, können Sie dies wie folgt festlegen:

# <a name="in-powershell---replace-variablename-and-variablevalue-with-the-correct-values"></a>In PowerShell - replace variableName and variableValue with the correct values
$env:variableName = "variableValue"

In der YAML müssen zwei Eigenschaften definiert werden, um anzugeben, dass die Anmeldeinformationen dieses Benutzenden in Umgebungsvariablen gespeichert werden:

emailKey: Die Umgebungsvariable, die zum Speichern der E-Mail-Adresse des Benutzenden verwendet wird.
passwordKey: Die Umgebungsvariable, die zum Speichern des Kennworts des Benutzenden verwendet wird.

Beispiel-YAML:

    - personaName: "User1"
      emailKey: "user1Email"
      passwordKey: "user1Password"

Beispiel-PowerShell zum Festlegen von Benutzeranmeldeinformationen basierend auf YAML:

$env:user1Email = "someone@example.com"
$env:user1Password = "fake password"

Siehe auch

Übersicht über die Power Apps Test Engine (Vorschauversion)
Power Apps Test Engine – Power Fx-Funktionen (Vorschauversion)