Format YAML du moteur de test Power Apps (préversion)

Les tests sont définis dans YAML en suivant les mêmes instructions que Power Fx. En savoir plus sur la grammaire de formule YAML Power Fx.

Consultez le dossier PowerApps-TestEngine/samples pour obtenir des exemples détaillés.

Définitions de schéma YAML

testSuite

Utilisé pour définir un test.

Comment identifier votre application dans le plan de test

Vous avez besoin de définir ou appLogicalNameappId d’identifier votre application. Ce que vous utilisez dépend de la définition de votre application dans une solution.

Applications basées sur des solutions (recommandées)

Lorsque vous définissez vos applications au sein de solutions, vos tests restent portables dans les environnements. Définissez la appLogicalName propriété pour indiquer que l’application est basée sur la solution.

Pour localiser le nom logique de l’application :

1. Ouvrir la solution contenant votre application dans Power Apps
2. Utilisez le nom (et non le nom complet) dans la liste. La valeur du nom inclut le préfixe de personnalisation pour l’éditeur de solution.

Applications autonomes

Lorsque votre application n’est pas définie dans une solution, vous devez utiliser la appId propriété.

Pour localiser l’ID de l’application :

1. Rechercher l’application dans la liste Power Apps
2. Ouvrir les détails et noter le GUID de l’ID d’application

NetworkRequestMocks

Pour les propriétés facultatives, si aucune valeur n’est spécifiée, le routage s’applique à tous. Par exemple, si method la valeur est Null, nous renvoyons la réponse fictive quelle que soit la méthode tant que les autres propriétés correspondent toutes.

Pour les applications Sharepoint/Dataverse/Connector, requestURL et method peut être identique pour toutes les requêtes. x-ms-request-method et x-ms-request-url dans les en-têtes peuvent avoir besoin d’être configurés dans ce cas pour identifier différentes demandes.

TestCases

TestSteps

• TestSteps peut utiliser n’importe quelle fonction Power Fx du moteur de test existant ou des fonctions de test spécifiques définies par cette infrastructure.
• La valeur doit commencer par un symbole de canal (|) pour autoriser les expressions YAML multilignes suivies d’un signe égal (=) pour indiquer qu’il s’agit d’une expression Power Fx
• Les fonctions doivent être séparées par un point-virgule (;).
• Les commentaires peuvent être utilisés et doivent commencer par des barres obliques inverses doubles (//).

Exemple 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

Permet de définir les paramètres des tests dans le plan de test.

extensionModules

Contient des données sur les extensions à activer.

Cet exemple montre comment activer l’espace de noms PowerFx Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

En savoir plus sur les fonctions en préversion

Considérations relatives à la région et à la langue

Le moteur de test prend en charge différents paramètres linguistiques et régionaux tels que les séparateurs décimaux et de liste. La testSettings.locale propriété contrôle ces comportements. Pour plus d’informations, consultez Support global dans Microsoft Power Fx.

Examinez ces exemples de configurations sur le dépôt GitHubPowerApps-TestEngine :

• Pour les régions utilisant des points-virgules comme séparateurs de liste
• Pour les régions utilisant des virgules comme séparateurs décimaux

exemple powerFxTestTypes

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

Cet exemple montre comment définir des types Power Fx personnalisés à utiliser dans vos cas de test. Le ControlName type est défini comme un enregistrement avec un seul Text champ, tandis que le Options type est défini comme une table d’enregistrements, chacun contenant un Name champ de type Text et un Value champ de type Number. Les types personnalisés peuvent être utilisés pour créer des scénarios de test plus complexes et spécifiques, ce qui améliore la flexibilité et la puissance de vos définitions de test.

exemple 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);

Ces exemples de fonction de test montrent comment définir des fonctions Power Fx personnalisées à utiliser dans vos cas de test. La WaitUntilVisible fonction utilise un sélecteur DOM pour attendre qu’un contrôle spécifié soit visible, à l’aide d’actions playwright. La fonction GetOptions récupère les options d’un contrôle spécifié à partir d’une application MDA (Model Driven App ), utilisant le contrôle Power Fx. Ces fonctions personnalisées améliorent la flexibilité et la puissance de vos définitions de test, ce qui permet de créer des scénarios de test plus complexes et spécifiques.

BrowserConfiguration

Chaque testSettings nécessite au moins un BrowserConfiguration.

environmentVariables

Vous pouvez stocker différents types de valeurs en tant que valeurs environnementales, mais le cas le plus courant consiste à stocker des informations d’identification avec une liste d’utilisateurs.

users

Pour garantir que les informations d’identification sont stockées de manière sécurisée, la définition de test référence les utilisateurs à l’aide d’un personaName. Le stockage des informations d’identification dans les fichiers de plan de test n’est pas pris en charge.

Exemple :

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

Il personaName est utilisé dans le cadre de la définition de test pour indiquer à quel utilisateur exécuter le test.

Mécanismes de stockage des informations d’identification pris en charge

Pour stocker les informations d’identification en tant que variables d’environnement, vous pouvez les définir comme suit :

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

Dans YAML, deux propriétés doivent être définies pour indiquer que les informations d’identification de cet utilisateur sont stockées dans des variables d’environnement :

• emailKey: variable d’environnement utilisée pour stocker l’e-mail de l’utilisateur.

Exemple YAML :

    - personaName: "User1"
      emailKey: "user1Email"

Exemple de PowerShell pour définir les informations d’identification de l’utilisateur en fonction de YAML :

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

Voir aussi

Vue d’ensemble du moteur de test Power Apps (préversion)
Fonctions Power Fx du moteur de test Power Apps (préversion)