Formato YAML del motor de pruebas de Power Apps (versión preliminar)

Las pruebas se definen en YAML siguiendo las mismas directrices que Power Fx. Obtenga más información sobre la gramática de fórmulas YAML de Power Fx.

Vea la carpeta PowerApps-TestEngine/samples para obtener ejemplos detallados.

Definiciones de esquema DE YAML

testSuite

Se usa para definir una prueba.

Identificación de la aplicación en el plan de prueba

Debe establecer o appLogicalNameappId para identificar la aplicación. El uso depende de si la aplicación se define dentro de una solución.

Aplicaciones basadas en soluciones (recomendadas)

Al definir las aplicaciones dentro de las soluciones, las pruebas permanecen portátiles entre entornos. Establezca la appLogicalName propiedad para indicar que la aplicación está basada en la solución.

Para buscar el nombre lógico de la aplicación:

1. Abra la solución que contiene la aplicación en Power Apps.
2. Use el nombre (no nombre para mostrar) de la lista. El valor de nombre incluye el prefijo de personalización para el publicador de soluciones.

Aplicaciones independientes

Cuando la aplicación no está definida dentro de una solución, debe usar la appId propiedad .

Para buscar el identificador de la aplicación:

1. Buscar la aplicación en la lista de Power Apps
2. Abra Detalles y anote el GUID del identificador de aplicación.

NetworkRequestMocks

En el caso de las propiedades opcionales, si no se especifica ningún valor, el enrutamiento se aplica a todos. Por ejemplo, si method es NULL, se devuelve la respuesta ficticia, sea cual sea el método, siempre que todas las demás propiedades coincidan.

En el caso de las aplicaciones de Sharepoint/Dataverse/Connector, requestURL y method pueden ser iguales para todas las solicitudes. x-ms-request-method y x-ms-request-url en los encabezados podrían tener que configurarse en ese caso para identificar diferentes solicitudes.

TestCases

TestSteps

• TestSteps puede usar las funciones existentes de power Fx del motor de pruebas o funciones de prueba específicas definidas por este marco.
• El valor debe comenzar con un símbolo de canalización (|) para permitir expresiones YAML de varias líneas seguidas de un signo igual (=) para indicar que es una expresión de Power Fx.
• Las funciones deben estar separadas por punto y coma (;).
• Los comentarios se pueden usar y deben comenzar con caracteres de barra diagonal inversa dobles (//).

Ejemplo de 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

Se usa para definir la configuración de las pruebas en el plan de pruebas.

extensionModules

Contiene datos sobre las extensiones que se van a habilitar.

En este ejemplo se muestra cómo habilitar el espacio de nombres de PowerFx Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

Más información sobre las funciones en versión preliminar

Consideraciones sobre la región y el idioma

El motor de pruebas admite varios idiomas y configuraciones regionales, como separadores decimales y de lista. La testSettings.locale propiedad controla estos comportamientos. Para obtener más información, consulte Compatibilidad global en Microsoft Power Fx.

Examine estas configuraciones de ejemplo en el repositorio de GitHub dePowerApps-TestEngine:

• Para las regiones que usan punto y coma como separadores de lista
• Para las regiones que usan comas como separadores decimales

Ejemplo de powerFxTestTypes

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

En este ejemplo se muestra cómo definir tipos personalizados de Power Fx para su uso en los casos de prueba. El ControlName tipo se define como un registro con un único Text campo, mientras que el Options tipo se define como una tabla de registros, cada uno de los cuales contiene un Name campo de tipo Text y un Value campo de tipo Number. Los tipos personalizados se pueden usar para crear escenarios de prueba más complejos y específicos, lo que mejora la flexibilidad y la eficacia de las definiciones de prueba.

Ejemplo de 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);

Estos ejemplos de funciones de prueba muestran cómo definir funciones personalizadas de Power Fx para su uso en los casos de prueba. La WaitUntilVisible función usa un selector DOM para esperar hasta que un control especificado esté visible, mediante acciones de Playwright. La función GetOptions recupera las opciones de un control especificado de una aplicación controlada por modelos (MDA), utilizando el control Power Fx. Estas funciones personalizadas mejoran la flexibilidad y la eficacia de las definiciones de prueba, lo que permite escenarios de prueba más complejos y específicos.

BrowserConfiguration

Cada testSettings requiere al menos un BrowserConfiguration.

environmentVariables

Puede almacenar diferentes tipos de valores como valores de entorno, pero el caso más común es almacenar información de credenciales con una lista de usuarios.

users

Para asegurarse de que las credenciales se almacenan de forma segura, la definición de prueba hace referencia a los usuarios mediante .personaName No se admite el almacenamiento de credenciales en archivos de plan de prueba.

Ejemplo:

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

personaName se usa como parte de la definición de prueba para indicar qué usuario debe ejecutar la prueba como.

Mecanismos de almacenamiento de credenciales admitidos

Para almacenar las credenciales como variables de entorno, puede establecerlas de la siguiente manera:

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

En YAML, se deben definir dos propiedades para indicar que las credenciales de este usuario se almacenan en variables de entorno:

• emailKey: la variable de entorno que se usa para almacenar el correo electrónico del usuario.

Ejemplo de YAML:

    - personaName: "User1"
      emailKey: "user1Email"

Ejemplo de PowerShell para establecer credenciales de usuario basadas en YAML:

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

Consulte también

Introducción al motor de pruebas de Power Apps (versión preliminar)
Funciones power Fx del motor de prueba de Power Apps (versión preliminar)