Automated Testing for Power Apps and Power Platform Solutions

Why do recorded UI tests for Power Apps keep breaking?

Because they check the surface of the app rather than what it does. A recorded test says "select this control, type into that box, expect this label to read X". Every one of those steps depends on a control name, a position, a screen layout or a timing the maker is free to change. Rename a control, move a field into a container, add a loading spinner or switch a gallery layout, and the test fails although no behaviour changed.

The opposite failure is worse. A UI test can pass while the data is wrong, because it only checked that a success message appeared, not that the right record was created with the right owner, status and amounts. For an auditor, the second failure is the one that matters.

Other causes stack up on top: sign-in and multi-factor prompts in unattended runs, tests sharing and changing the same records, delegation differences between a small test environment and production data, and slow environments making timing unpredictable. Teams respond by re-recording, the suite drifts out of date, and within months nobody trusts it.

What does a data-and-state-first testing approach look like?

Every test follows the same three steps, and none of them needs the screen. Arrange: put known records into a test environment. Act: perform the operation the way the system performs it. Assert: read Dataverse and check the state is exactly what the requirement says.

For example, "a claim above the approval threshold must be routed to a manager and cannot be marked paid until approved" becomes a test that creates a claim through the Web API, checks that the approval record and status are what the rule demands, tries to set the status to paid and expects the platform to refuse, then approves and checks the change is now accepted and audited. That test does not care what the form looks like, so it survives redesigns, and it tests the rule an auditor asks about.

• Assert records, columns, statuses, owners, relationships and whether an operation was refused, not labels on a screen.
• Capture the state before the action as well as after, so the test proves a change rather than a coincidence.
• Name each test after the requirement or control it proves, not after the screen it touches.
• Make each test create and clean up its own records, tagged with a run identifier, so tests never depend on each other.

Where must business logic live for it to be testable without the canvas?

On the server, in Dataverse and flows, not only in button formulas. If the rule that sets a status or calculates an amount lives in the OnSelect of a canvas app button, the only way to test it is to press the button, and an integration or a second app can bypass it entirely.

Rules that matter for compliance belong where every write passes through: table business rules, required columns, plug-ins, Dataverse custom APIs or low-code functions where your environment supports them, and cloud flows for asynchronous steps. The canvas app then calls that logic and displays the result, and the tests exercise the same logic the app uses. Moving logic out of a large app without breaking it is covered in our guide to refactoring a tangled Power Apps app, and unit testing the plug-in code itself is covered in plug-in unit testing for Dynamics 365.

Be honest about what this means: for an existing app with logic in formulas, the first testing work is often a small redesign, not a test suite.

How do you drive test scenarios through the Web API or Power Automate instead of the UI?

Use a small test project that talks to Dataverse as an application user, run from the pipeline. The Dataverse Web API or the Dataverse SDK for .NET can create records, call custom APIs, trigger the operations your app performs and read the results, and standard test frameworks such as xUnit, NUnit or a JavaScript test runner give you assertions and machine-readable result files.

How do you keep a seeded test dataset and reset it between runs?

Treat test data as part of the solution: versioned, repeatable and never copied from production. A test that passes only on the records someone happened to leave in the environment is not evidence.

• Keep reference data, such as products, price lists, teams and configuration records, in files in the repository and load it with the Configuration Migration tool or a seeding script after each deployment.
• Use alternate keys on seeded records so loading is an upsert and can be repeated safely.
• Have each test create its own transactional records with a run identifier, and delete everything with that identifier at the end.
• Reset the whole environment on a schedule, by restoring a known backup or copying a clean baseline environment, so leftovers from failed runs cannot accumulate. Check current Microsoft documentation for backup, restore and copy options and their timing.
• Never use real personal data in test environments; generate realistic fictional records instead.
• Run automated tests only in a dedicated test environment, never in production.

When are UI tests still worth having, and which tools are the honest options?

Keep UI tests for a handful of journeys where the screen itself is the behaviour: the main path a user takes through a critical form, a screen that shows or hides fields by role, and a smoke test that the app opens after deployment. Once the rules are tested through data, a few UI tests are enough, and a few can be kept healthy.

How do you run Power Platform tests in a deployment pipeline?

Make testing a stage the release cannot skip. The build and release shape, pac commands and managed solution handling are covered in our Power Platform ALM guide; testing adds these steps to the same Azure DevOps or GitHub Actions pipeline.

• Build or pack the managed solution from source control and record its version and the commit it came from.
• Run pac solution check and fail the build on the severities you agree.
• Deploy the managed solution to the dedicated test environment with its deployment settings file.
• Load seeded reference data, then run the data-and-state tests as an application user with credentials held in the pipeline's secure variables.
• Run the small set of UI tests against the same environment.
• Publish result files to the pipeline so passes and failures appear on the run, and keep them as artifacts.
• Allow promotion to production only when tests pass and a named approver signs off.

What test evidence does an auditor want to see?

An auditor wants to trace a requirement or control to proof that it was tested, on the version that went live, before it went live, with the result recorded somewhere that cannot quietly be edited. A pipeline run holds nearly all of that if you design for it. Check with your auditor which controls apply and how long evidence must be kept.

How does a small team with no dedicated QA keep automated tests running?

By testing less, but testing what matters, and making the tests part of how changes are made rather than a separate project. A suite that tries to cover every screen is abandoned; a suite that covers the rules an auditor or a customer would notice survives.

Start with the controls and rules that carry risk: approvals, calculations, permissions, status transitions and integrations. Write a test for each, then add one for every defect found, so a bug fixed once stays fixed. The developer who changes a rule updates its test in the same pull request, and a change without a passing test does not merge. Keep the suite fast enough to run on every change. Quarantine a flaky test immediately and fix or delete it within days, because tolerated flakiness teaches everyone to ignore red runs. Review the traceability list quarterly against the current requirements. Audit logging of the data itself, which complements test evidence, is covered in our Dynamics 365 audit trail guide.

Does automated testing change whether the solution belongs on Power Platform or a custom build?

Rarely on its own. Power Platform solutions can be tested to an audit standard once logic sits in Dataverse and releases run through a pipeline, and what a Power Platform engagement covers is on our Power Platform consulting page.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If a solution has outgrown low-code, with most rules in custom code and a need for full control over testing, hosting and release, a custom-built CRM or application on React, Node.js, PostgreSQL or .NET uses conventional test tooling end to end and carries no Microsoft licensing.

How does Solzet help set up automated testing for Power Apps before an audit?

We start from the controls the audit will examine and map each one to where its logic lives today. Then we move rules that only exist in canvas formulas to Dataverse where needed, build the seeded test environment, write data-and-state tests for the risky rules, add a small set of UI tests, and wire it all into your pipeline with a traceability list and retained results, so the evidence exists before the auditor asks. Your team keeps and extends the suite afterwards.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. Pipelines and managed solutions are covered in our PAC CLI and pipelines guide, and plug-in tests in our plug-in unit testing guide.