Why I’m finally building UI tests for Power Platform & Dynamics 365

During my career, I have worked on several big Dynamics 365 projects. In one of them specifically, we had over a thousand unit tests running in a CI/CD-pipeline. All tests ran at each deploy and all passed. Every time. But our end-users still reported bugs in production almost every week.

The thing is, we had exactly zero end-to-end UI tests. Not one.

Not because the team was lazy. Not because we were incompetent. These were some of the best Dynamics consultants I’ve ever worked with. But every sprint, the UI test story slid further down the backlog, because the cost was too high compared to value-adding stories we had to ship now.

And in more than fifteen years of Dynamics 365/Power Platform work, that’s the closest I’ve come to seeing a really good test setup. After that project I told myself I’d get into testing properly, but I never did. At a community event with Power Platform Community Sweden I was introduced to Playwright and with this tool, I did get a bit further, but still not very far.

Then, while I was preparing for a talk on Playwright testing at DynamicsMinds 2026, Microsoft shipped the Power Platform Playwright Toolkit and for the first time I wanted to drop everything else. Of course this meant I had to rewrite my session, but it was definitely worth it. I had to tell the world about this new way of building UI-tests for Dynamics 365 and Power Platform.

This is the written version, for anyone who couldn’t be in the room.

The case

UI testing for Power Platform always lost in backlog prioritization for rational economic reasons. It was just too difficult to get started. As of April 2026, those reasons are no longer true. Three specific things changed, which made it so much easier to build UI tests.

That’s not a moral argument about test discipline. It’s an economic one about what just got cheaper.

1 – Simplified authentication

For years, authentication was the first blocker. Authenticating into a model-driven app used to be very fragile. MFA on every test run isn’t workable; bypassing MFA isn’t a security conversation any project ever wins. So teams often got stuck here, right before getting their first test case created. If they did get past the first hurdle, they would spend way too much time on dealing with token expiry, or kept secrets in some insecure location. And usually only one person on the team knew how the whole thing worked.

The new Power Platform Playwright Toolkit (PPPT) ships dual-domain storage state acquisition out of the box. You log in once, interactively, with or without MFA. The toolkit captures the logged in session and every test run after that reuses the stored session, without the need to authenticate again.

And there is no need to bypass MFA. Setting up test users without MFA requirements used to be a real recommendation from Microsoft. I still haven’t met the information security person that liked that idea… Now we don’t need to bypass MFA, we can simply handle it using the toolkit.

That’s not nothing. That’s the thing that used to kill UI testing initiatives in week one, gone.

2 – Finding elements much easier

The second big change is how to handle the DOM (i.e. the webpage structure) and creating custom selectors for finding your elements on a form page. Dataverse forms render in iFrames, ribbons reshape between releases, grid IDs change when columns reorder. You’d ship a test, then watch it break on the next release wave. Keeping your test cases working was too much work.

PPPT ships pre-built page objects: ModelDrivenAppPage, CanvasAppPage, GenUxPage, FormComponent, GridComponent. They know what a form is on a Dataverse page. You stop creating new selectors and start writing what the test should verify. And the tests become much more readable for a non-techie person, like this:

// Set the account name in field name on the form    
await myApp.form.setAttribute('name', accountName);

// Save via the command bar button and wait for the server to confirm
await myApp.commanding.save();

You still need to understand selectors and the DOM concept for the day you debug something the toolkit doesn’t cover, or you have a custom PCF that needs its own page object. But you no longer need to know that before you write your first test.

3 – Authoring stopped being a TypeScript task

This is maybe the biggest change. Even with authentication and selectors solved, writing a test still needed someone fluent in TypeScript. That someone usually had a queue of at least three other things. So the test didn’t get written this sprint. Or the next one.

Playwright now ships an MCP server. GitHub Copilot, Claude Code, and Cursor can author tests against the PPPT vocabulary directly in your IDE. You describe what should happen in plain English; the AI writes the TypeScript.

I tried this. Wrote three test cases that together log into Sales, creates an account, adds a primary contact, verifies both appear in a view, then cleans up. End to end, including a quick review and one small refactor, took about 10-15 minutes. In 2024 that scenario would have taken a week to complete.

And with the right agent scaffolding and a few additional instructions you could probably generate all tests for a whole application in just one prompt. That is actually my next experiment, stay tuned!

The bigger implication: the person writing the test no longer has to be the strongest engineer on the team. It can be the functional consultant who actually knows what the business expects.

Tests can finally own their world

Once authoring is cheap, the test suite can do something we always wanted: own its own world. Well, to be honest, it always could but it was never economically feasible to let it.

We used to live in a shared environment with mutable data, where tests assumed records existed in a particular shape. When the data drifted, which it often did, the tests broke. So even when you had managed to get a few working tests up and running, you still had to put a lot of effort into maintaining them.

The new pattern: the first thing in your suite isn’t a test, it’s a seeding case. It creates the records your scenarios need. Every test run starts from a known state. And before wrapping up, the test suite can also tear down and remove the records it created.

This has been the right answer in mature software engineering for at least twenty years, and now we can finally afford to do it.

What to do on Monday morning

But the hardest part of UI testing on Power Platform was never the tool itself. It was getting the test story prioritized in sprint planning, because of the tool. Now that we have new tools, here are three sentences you can use at planning, each anchored in one of the changes above:

When someone says “this’ll take too long to set up”: “We can have the first test running by end of day — Microsoft ships a starter kit with auth solved. The only setup we need is picking the flow.”

When someone says “tests are too brittle, they’ll break every release”: “We’re not maintaining custom selectors anymore. Page objects come pre-built for the standard surfaces. When forms change, we update the test’s expectations — not the plumbing.”

When someone says “we’ll spend more time writing tests than features”: “With Copilot in the IDE, writing a test takes about as long as describing the scenario in the ticket. We’re not asking for a new skill — we’re asking for one ticket.”

Then, during the sprint itself, this is what I recommend you do. Spend about one hour per day, maximum two, not whole days. After all, your day job won’t pause for this, so if you try too much you will give up by Wednesday:

Day 1–2. Fork the PPPT samples repo, point it at your TEST environment, acquire storage state for your test user. Generate a simple smoke test, just to see that the infrastructure is working.
Day 3. Write the seeding case first, i.e. the script that creates the records your tests will use. This is what makes the suite own its world.
Day 4–5. Pick one business-critical flow. Not the easiest one. The one that bleeds when it breaks. Write the behavioral test against the seeded data.
End of sprint. Wire it to CI on PR. One test, on every pull request, visible to the team.
The official samples repo includes a working pipeline you can start from.
Next sprint planning. Show your working test at next demo.
Use the three sentences. Get ticket number two.

The goal of sprint one isn’t to test everything. It’s to ship one test, on CI, by Friday. That’s the only goal.

What hasn’t changed

I want to be honest: The new toolkit (PPPT) doesn’t fix everything. You still need a tight ALM story with separated DEV/TEST/PROD environments. You still need to deal with security role drift between environments. Managed solution upgrades will still surprise you. Frameworks don’t fix ALM. ALM is still on you.

What the toolkit fixes is the test infrastructure cost, not the organizational cost. Both matter.

Where to go from here

Everything I cover above — the three sentences for sprint planning, the five-day plan, and the MFA edge cases I’ve worked through in a real project — is in a small companion repo I’ve started: power-platform-playwright-playbook. The idea is to add to this repo as I add more experience.

Useful official links:

If you’ve tried UI testing for Power Platform before and parked it — which, going by the audience in my session, is most of us — I’d love to know what specifically pushed you off. Was it authentication, finding the right selectors, the authoring cost, or something else? The fixes I’ve described address my own problems. Do they address yours?

Let me know in the comments, or drop me a message on LinkedIn.