Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

feature-canvas-app-testing.mdv1 · history
CurrentApplies to CanvasUpdated last monthSource Microsoft Learn

What it does

Test Studio is a low-code UI test harness for canvas apps. You write test steps as Power Fx expressions or record your interactions to generate them, group cases into suites, assert on expected results, and replay in Studio, in a browser, or from a deployment pipeline.

Key facts

  • You must be the creator or a co-owner of the app to test it in Test Studio.
  • Structure is test suite > test case > test step. Steps are Power Fx, using both normal app functions and test-specific ones.
  • Test cases inside a suite run sequentially and share app state. The app isn't reloaded between cases — a case that ends on Screen 5 hands Screen 5 to the next case.
  • Assertions are expressions that must evaluate to true. A false assertion fails the case.
  • Not covered: components, PCF code components, nested galleries, media controls, person-type columns, and any control not listed in the Select and SetProperty function docs.
  • The formula-level error management experimental feature must be turned on for the app.
  • Test Studio is incompatible with the experimental Git version control feature and won't work properly if that's enabled.
  • Microsoft's own guidance is explicit that you shouldn't rely on test automation alone — manual testing sits alongside it.

When to use / skip

Automate the regression path on an app that's business-critical, changes often, and has stable core screens — that's where the payback is, because regression testing eventually costs more than building the features. Skip it on an app that's still being designed weekly, because you'll spend more time repairing tests than running them. And check the exclusion list before you promise anything: an app built out of components and PCF controls, which is what a well-architected canvas app tends to look like, is largely untestable in Test Studio. That's an awkward conversation to have after you've committed to a test automation deliverable.

Configuration decisions

  • Which cases are worth automating: repetitive ones, high business impact ones, stable ones, and ones needing multiple data sets.
  • How suites are cut — by feature, since state carries across cases in a suite and that's either a feature or a trap depending on how you've grouped them.
  • Whether each case resets itself by navigating to the start screen as its first step, or deliberately relies on the previous case's state.
  • Where tests run: in Studio during development, in a browser, or wired into a release pipeline.
  • What test data the tests run against, and how it's reset between runs — Test Studio won't do this for you.

Gotchas

  • Shared state across cases in a suite bites the first time a case fails halfway and leaves the app somewhere unexpected for every case after it.
  • Components and PCF controls aren't supported. If the app is built well, large parts of it can't be tested here.
  • Big multi-action test steps make failures hard to isolate. One action per step is the documented advice and it's right.
  • One monolithic test case means a single failed assertion leaves everything after it untested.
  • Turning on Git version control silently breaks Test Studio.
  • Tests are app artefacts, so they move with the app — and they also break with the app whenever a control is renamed.

Consultant notes

  • Don't sell test automation as a canvas app deliverable without walking the exclusion list against the actual app design first. This is the fastest way to over-commit on a Power Apps project.
  • Frame Test Studio as regression protection for a stable app, not as a way to reduce the initial test effort. It increases the initial effort and reduces the later effort.
  • Manual test scripts are still required. Write them anyway — they're what the client's UAT team will use, and they're the source material for the automated cases.
  • If the client's real need is proper source control, branching and CI, that's solutions and pipelines. Say so early rather than trying to make Test Studio carry a story it can't.
  • Set a naming convention for controls before writing tests, because renaming a control after the fact breaks every step that references it.

Worth revisiting if component and PCF support ever lands, or if the Git version control incompatibility is resolved.

Was this accurate?