A while back I wrote an introduction post about automated testing Power Apps using Power Automate Desktop. Today, I’m going to look at automated testing in more detail focussing on the various controls available.
The first steps
Table of Contents
I’m starting this post with a simple app, where I press a button and then a text is displayed giving me the time that I pressed the button.

As a general setup for my test, I’ve created a Desktop flow with three sub flows. In this case it may be a bit of overkill to create the sub flows but once we get into more complicated apps the subflows will become a useful way of organising our tests.

Additionally I like to keep our tests flexible. With these subflows I can reorder the various steps of testing quite quickly. I could even decide to use various test paths by adding some conditional logic in my Desktop flows.
Open an app in a browser
My first subflow is to open the browser. I’m using Chrome, in the example below, but we could decide to open the same tests in multiple browsers.

For the app url, I find it easier to user the &hidenavbar=true parameter. This makes sure that we don’t have the clutter of the Power Apps bar appear. I also make sure that we use Maximized as the Windows state.

Now when you run the Flow you might find the “Failed to assume control of Chrome.” error message. I found a number of reason why this can happen. Always make sure that you have the latest version of your browser, Power Automate Desktop app and Power Automate Desktop Plugin in the browser. If all fails then sometimes a reboot will also do the trick.

If you use multiple profiles like I do (I use a browser profile for each of my clients), then you might find that once Power Automate Desktop is connected to one profile and you happen to get Power Automate Desktop to connect to a different profile that things get a bit messed up. Opening a session within the required profile resolves that issue.
Now that we have our browser running we can test the button.
Handling buttons during automated testing
My next subflow will press the button in my app. We can do this using the Press button in window action.

The Press button in window action can be configured by configuring the UI Element property. You can simply select the UI element in the browser.

In my example that will work, however I have seen this fail quite often. Especially when your Power Apps screens are more complicated. This is where it will be useful to understand the HTML that Power apps generates better.

Once I have recorded the button’s UI element in Power Automate Desktop, I can open the Selectors that are used to select the control in my browser.

However, When we look into our browser’s html code we will not find the exact same text that our selector is looking for.

It is not until element 9 that we find a div element that matches our recorded button control.

Now I can untick all the elements before element 9.

This makes my preview selector also a lot easier to understand. If you only have one button (with the name Button) in your app then you could take all the previous elements of the selector away as well.
group[Class="player-app-container"][Id="playerAppContainer"] >
document[Class="player-app-frame"][Id="fullscreen-app-host"] >
document[Id="RootWebArea"] >
button[Class="appmagic-button-container no-focus-outline"][Name="Button"]
Looking at the last line in that Selector preview and the HTML for the button, we can quite quickly see the issue if we have multiple buttons on our screen.
<button class="appmagic-button-container no-focus-outline" data-control-part="button" data-bind="
event: {
click: handleClick,
pointerdown: handleMouseDown,
pointerup: handleMouseUp,
pointerout: handleMouseOut
},
attr: {
title: properties.Tooltip,
disabled: viewState.displayMode() !== AppMagic.Constants.DisplayMode.Edit
}
" title="" tabindex="0">
<div class="appmagic-button middle center" touch-action="pan-x pan-y" data-bind="
style: {
fontFamily: properties.Font,
fontSize: properties.Size,
color: autoProperties.Color,
fontWeight: properties.FontWeight,
fontStyle: properties.Italic,
textAlign: properties.Align,
paddingTop: properties.PaddingTop,
paddingRight: properties.PaddingRight,
paddingBottom: properties.PaddingBottom,
paddingLeft: properties.PaddingLeft,
},
css: {
top: properties.VerticalAlign() === 'top',
middle: properties.VerticalAlign() === 'middle',
bottom: properties.VerticalAlign() === 'bottom',
left: properties.Align() === 'left',
right: properties.Align() === 'right',
center: properties.Align() === 'center',
justify: properties.Align() === 'justify',
disabled: viewState.displayMode() === AppMagic.Constants.DisplayMode.Disabled,
underline: properties.Underline,
strikethrough: properties.Strikethrough,
readonly: viewState.displayMode() === AppMagic.Constants.DisplayMode.View
}
" style="font-family: "Open Sans", sans-serif; font-size: 15pt; color: rgb(255, 255, 255); font-weight: 600; font-style: normal; text-align: center; padding: 5px;">
<div class="appmagic-button-label no-focus-outline" data-control-part="text" spellcheck="false" data-bind="inlineEditText: properties.Text">Button</div>
</div>
</button>
If I now update my app slightly and I’m adding a button.

I’ve updated the way the buttons display. I gave one button the text Button 1 and the other one Button 2. If we now rerun our test then we will get the “Failed to press button” error message. Can we make our automated testing script work?

All we have to do, to make this work, is to update the Name attribute of our Button element.

So this works if every button has a unique display name. In Power Apps however could have the same button displayed on a single screen.
Adding galleries to the app
If our gallery has 5 items, and each button includes some text to make the button’s display name unique then we can still use the above methodology of selecting the button that we want to press in our app. Power Automate Desktop will handle this perfectly fine.

But what happens if our button’s are all like this:

Or how about using icons instead of buttons …
I’m first going to have a look at the first question. We have 5 buttons with the same text. This is where we can use the Ordinal property as shown below.

The ordinal property starts counting at 0. So the above example will press the fourth edit button found within our app. When we look at Icons later on we will see that we can further enhance our automated testing scripts. Hardcoding the reference to the nth button isn’t nice when we decide to add an additional button to our screen.
Handling Icons during automated testing
I’ve updated my app a bit and added two icons next to the buttons. Getting Power Automate Desktop to select the icons that I want is a bit trickier. So this is a good time to investigate the custom selectors a bit further.

We can use the Click UI element in window to do the same as before however you might run into some trouble here.

In my case, I had a poorly developed app and my icon html would look something like the code below. Well nothing wrong with that. It all looks quite ok.
<div class="powerapps-icon no-focus-outline" touch-action="pan-x pan-y" data-control-part="icon" data-bind="
event: {
click: handleClick
},
shortcut: {
provider: shortcutProvider,
capture: false
},
attr: {
title: properties.Tooltip() || null,
role: (properties.TabIndex() < 0) ? (!!properties.AccessibleLabel() && 'img') : 'button',
'aria-label': properties.AccessibleLabel() || null,
'aria-disabled': (properties.TabIndex() >= 0) && (viewState.displayMode() !== AppMagic.Constants.DisplayMode.Edit),
'aria-hidden': properties.TabIndex() < 0 && !properties.AccessibleLabel()
},
style: {
cursor: viewState.displayMode() !== AppMagic.Constants.DisplayMode.Edit ? 'default' : 'pointer',
transform: iconRotationComputed()
}
" data-shortcut-id="1" aria-hidden="true" style="cursor: pointer; transform: rotate(0deg);">
<div class="icon-svg-container" aria-hidden="true" data-bind="
attr: {
width: properties.Width,
height: properties.Height,
preserveAspectRatio: properties.PreserveAspectRatio() ? 'xMidYMid meet' : 'none',
},
style: {
paddingTop: properties.PaddingTop,
paddingRight: properties.PaddingRight,
paddingBottom: properties.PaddingBottom,
paddingLeft: properties.PaddingLeft
}
" width="64px" height="64px" preserveaspectratio="xMidYMid meet" style="padding: 0px; pointer-events: none;"><svg xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 32 32" data-appmagic-icon-name="Basel_Check" width="64px" height="64px" fill="rgba(0, 18, 107, 1)" style="display: block;"><title></title>
<polygon points="10,24.6 2.7,17.3 1.3,18.7 10,27.4 30.7,6.7 29.3,5.3 "></polygon>
</svg></div>
</div>
However Power Automate Desktop will not be able to find my icons. There is a quick fix to this. Although testing shouldn’t result in chnages to the app for testing sake. Best practice should be applied anyway.
When you use Icons in your app you should make sure that you have set the AccessibleLabel property.

The AccessibleLabel will make it possible access the icon with the selector recording tools. And we can now select our icon.
button[Class="powerapps-icon no-focus-outline"][Name="My Trash Icon"]
If you are using your icons in a gallery or if you have multiple icons that are the same, do make sure that all the AccessibleLabels have been set to a unique value.
Automate testing to Edit forms
I’ve now updated my app to contains a simple form that creates a record in a Dataverse table.

A simple subflow can now populate each of the fields.

The first step is to focus on a text field. It is a good idea to do this all the time as your field might not be visible on your screen. Especially for longer forms it is useful to focus on the field first so that it can be found.
To select the field that we want to populate we can use the eq function as we found earlier in galleries. The following code will focus on the first text field found.
edit[Class="appmagic-text mousetrap block-undo-redo"]:eq(0)
If you prefer to not hardcode the order of the fields then the AccessibleLabel solution used earlier with icons can be used as well of course.
Then to populate a field with some text we can reuse the same control as with the focus action. The Text To Fill-in can contain any information that you want to test.

Now that we have looked at buttons, icons, fields we will find that many apps can be tested using Power Automate Desktop.
The next steps
To make all everything in your app tested using Power Automate Desktop flows can mean that you have to create a lot of child flows. In the next post in this series I will have a look at how we can feed Power Automate Desktop with a configuration file. This configuration file contains all the variable elements. So that we don’t have to keep hard coding our whole test plan. One simple script can then be picked up by our Test Engine flows developed in Power Automate Desktop. If you are interested then please subscribe on SharePains.com and you’ll receive a notification about my next post.
Discover more from SharePains
Subscribe to get the latest posts sent to your email.