.NET MAUI UI Testing

Boundary

Keep UI automation in projects separate from ordinary unit and integration tests.
Use UI tests for behavior that depends on real controls, binding, navigation, accessibility identifiers, platform rendering, or full user interaction.
Keep business rules and ViewModel state transitions under dotnet-testing unless the risk exists only in the running UI.
Preserve the project's existing UI automation stack.
For a new MAUI UI automation setup, follow Microsoft's current Appium structure and NUnit sample unless project instructions specify otherwise.

Give every element that a test must locate a unique, stable AutomationId.
Treat AutomationId as a test-automation contract; do not derive selectors from display text that can be localized or changed.
Handle accessibility semantics separately; do not treat AutomationId as a substitute for semantic properties, accessible names, hints, or platform accessibility checks.
Keep UI-test hooks limited to UI identification and platform launch requirements. Do not add production branches or alternate behavior for tests.
Apply platform launch configuration required by the actual application id and target platform.