Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Note
Preview features aren’t meant for production use and may have restricted functionality. These features are available before an official release so that customers can get early access and provide feedback.
Tests are defined in YAML following the same guidelines as Power Fx does. Learn more about the Power Fx YAML formula grammar.
View the PowerApps-TestEngine/samples folder for detailed examples.
YAML schema definitions
Property | Description |
---|---|
testSuite | Defines one test suite, the test cases in the test suite and configuration specific to the test suite |
testSettings | Defines settings for the test suite that are reused across multiple test cases |
environmentVariables | Defines variables that could potentially change as the app is ported across different environments |
testSuite
Used to define one test.
Property | Type | Description |
---|---|---|
persona |
string | Required. The user that is logged in to perform the test. Must match a persona listed in the Users section. |
testCases |
TestCases | Required. Defines test cases in the test suite. Test cases contained in test suites are run sequentially. The app state is persisted across all test cases in a suite. |
testSuiteName |
string | Required. The name of the test suite. |
appLogicalName |
string | Optional. The logical name of the app that is to be launched. It can be obtained from the solution. For canvas apps, you need to add it to a solution to obtain it. See How to identify your application in the test plan |
appId |
Guid | Optional. The ID of the app that is to be launched. Required and used only when appLogicalName isn't present. App ID should be used only for canvas apps that aren't in the solution. See How to identify your application in the test plan |
networkRequestMocks |
NetworkRequestMocks | Optional. Defines network request mocks needed for the test. |
onTestCaseComplete |
string | Optional. Defines the steps that need to be triggered for every test case in a suite after the case finishes executing. |
onTestCaseStart |
string | Optional. Defines the steps that need to be triggered for every test case in a suite before the case begins executing. |
onTestSuiteComplete |
string | Optional. Defines the steps that need to be triggered after the suite finishes executing. |
testSuiteDescription |
string | Optional. Additional information describes what the test suite does. |
How to identify your application in the test plan
You need set either appLogicalName
or appId
to identify your application. Which you use depends on whether your app is defined within a solution.
Solution-based apps (recommended)
When you define your apps within solutions your tests remain portable across environments. Set the appLogicalName
property to indicate that the app is solution based.
To locate the app's logical name:
- Open the solution containing your app in Power Apps
- Use the Name (not Display name) in the list. The name value includes the customization prefix for the solution publisher.
Standalone apps
When your app isn't defined within a solution, you need to use the appId
property.
To locate the ID of the app:
- Locate the app in the Power Apps list
- Open Details and note the App ID GUID
NetworkRequestMocks
Property | Type | Description |
---|---|---|
requestURL |
string | Required. The request URL that gets mock response. Glob patterns are accepted |
responseDataFile |
string | Required. A text file with the mock response content. All text in this file is read as the response |
headers |
array | Optional. A list of header fields in the request in the format of [fieldName: fieldValue] |
method |
string | Optional. The request's method (GET, POST, etc.) |
requestBodyFile |
string | Optional. A text file with the request body. All text in this file is read as the request body |
For optional properties, if no value is specified, the routing applies to all. For example, if method
is null, we send back the mock response whatever the method is as long as the other properties all match.
For Sharepoint/Dataverse/Connector apps, requestURL
and method
can be the same for all requests. x-ms-request-method
and x-ms-request-url
in headers could need to be configured in that case to identify different requests.
TestCases
Property | Type | Description |
---|---|---|
testCaseName |
string | Required. The name of the test case that is used in reporting success and failure |
testSteps |
TestSteps | Required. A set of Power Fx functions describing the steps needed to perform the test case. See TestSteps example |
testCaseDescription |
No | Optional. Additional information describes what the test case does |
TestSteps
TestSteps
can use any existing Test Engine Power Fx functions functions or specific test functions defined by this framework.- The value should start with a pipe symbol (
|
) to allow for multiline YAML expressions followed by an equals (=
) sign to indicate that it's a Power Fx expression - Functions should be separated by a semicolon (
;
). - Comments can be used and should start with double backslash characters (
//
).
TestSteps example
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
Used to define settings for the tests in the test plan.
Property | Type | Description |
---|---|---|
browserConfigurations |
BrowserConfiguration[] | Required. A list of browser configurations to be tested. At least one browser must be specified. |
extensionModules |
extensionModules | Optional. Contains data about extensions to enable. |
filePath |
string | Optional. The file path to a separate yaml file with all the test settings. If provided, it will override all the test settings in the test plan. |
headless |
boolean | Optional. Default is true. If set to false, the browser shows up during test execution. |
locale |
string | Optional. The locale/culture syntax in which the test cases or test steps are written in. If unspecified, CultureInfo.CurrentCulture is used for the locale by default for parsing the test steps. See Region and language considerations |
recordVideo |
boolean | Optional. Default is false. If set to true, a video recording of the test is captured. |
timeout |
integer | Optional. Timeout value in milliseconds. Default is 30,000 milliseconds (30s). If any operation takes longer than the timeout limit, it ends the test in a failure. |
powerFxTestTypes |
name value pair |
Optional. A list of type name and Power Fx type definitions. See powerFxTestTypes example |
testFunctions |
description code pair |
Optional. A list of description and Power Fx function definitions. See testFunctions example |
extensionModules
Contains data about extensions to enable.
Property | Type | Description |
---|---|---|
enable |
bool | Whether or not extension modules are enabled. |
allowPowerFxNamespaces |
list | List of the PowerFx namespaces to enable. |
parameters |
key value pairs | Properties with values to control extension modules. At this time, only the boolean enableDataverseFunctions parameter is valid for this. |
This example shows how to enable the PowerFx Preview
namespace:
testSettings:
extensionModules:
enable: true
allowPowerFxNamespaces:
- Preview
Learn more about preview functions
Region and language considerations
Test Engine supports various language and regional settings such as decimal and list separators. The testSettings.locale
property controls these behaviors. For more information, see Global Support in Microsoft Power Fx.
Look at these sample configurations on the PowerApps-TestEngine GitHub repository:
powerFxTestTypes example
powerFxTestTypes:
- name: ControlName
value: |
{ControlName: Text}
- name: Options
value: |
[{Name: Text, Value: Number}]
This example demonstrates how to define custom Power Fx types for use in your test cases. The ControlName
type is defined as a record with a single Text
field, while the Options
type is defined as a table of records, each containing a Name
field of type Text
and a Value
field of type Number
. Custom types can be used to create more complex and specific test scenarios, enhancing the flexibility and power of your test definitions.
testFunctions example
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);
These test function examples demonstrate how to define custom Power Fx functions for use in your test cases. The WaitUntilVisible
function uses a DOM selector to wait until a specified control is visible, using Playwright actions. The GetOptions function retrieves the options for a specified control from a Model Driven App (MDA), utilizing the Power Fx control. These custom functions enhance the flexibility and power of your test definitions, allowing for more complex and specific test scenarios.
BrowserConfiguration
Every testSettings requires at least one BrowserConfiguration
.
Property | Type | Description |
---|---|---|
browser |
string | Required. The browser to be launched when testing. Should match the browsers supported by Playwright. |
device |
string | Optional. The device to emulate when launching the browser. Should match the devices supported by Playwright |
screenHeight |
integer | Optional. The height of the screen to use when launching the browser. If specified, screenWidth must also be specified. |
screenWidth |
integer | Optional. The width of the screen to use when launching the browser. If specified, screenHeight must also be specified. |
environmentVariables
You can store different types of values as environmental values, but the most common case is storing credential information with a list of users.
users
To ensure credentials are stored in secure manner, the test definition references users using a personaName
. Storing credentials in test plan files isn't supported.
Example:
environmentVariables:
- users:
- personaName: "User1"
emailKey: "user1Email"
- personaName: "User2"
emailKey: "user2Email"
The personaName
is used as part of the test definition to indicate what user to run the test as.
Supported credentials storage mechanisms
To store credentials as environment variables, you can set them as follows:
# In PowerShell - replace variableName and variableValue with the correct values
$env:variableName = "variableValue"
In the YAML, two properties need to be defined to indicate that this user's credentials are stored in environment variables:
emailKey
: The environment variable used to store the user's email.
Example YAML:
- personaName: "User1"
emailKey: "user1Email"
Example PowerShell to set user credentials based on YAML:
$env:user1Email = "someone@example.com"
See also
Power Apps Test Engine overview (preview)
Power Apps Test Engine Power Fx functions (preview)