[Testing] Feature Matrix UITest Cases for VisualStateManager

[LogishaSelvarajSF4525]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

This pull request adds new VisualStateManager feature matrix pages for Button, CheckBox CollectionView, Entry, Label, Slider and Switch controls, providing comprehensive demos and test cases for visual state management. These additions enhance the test suite by enabling users to interactively explore and verify VisualStateManager behaviors such as Normal, Selected, PointerOver, Disabled, Focused, and Pressed across different controls

New VisualStateManager Feature Matrix Functionality

• Added a new entry for “VisualStateManager Feature Matrix” to the Core Views gallery, allowing easy navigation to the new demo pages from the main test app UI.
• Implemented dedicated feature matrix pages covering the following controls:
• Entry – Demonstrates visual states such as Normal, Focused, and Completed with interactive input validation and styling updates.
• Button – Showcases Normal, Pressed, PointerOver, Disabled, and Focused states with dynamic transitions.
• CollectionView – Demonstrates item-level states such as Normal, Selected, Disable and PointerOver with interactive selection behavior.
• CheckBox – Covers Normal, Checked, Unchecked, and Disabled states with dynamic styling.
• Label – Validates visual state transitions including Normal and Disabled scenarios.
• Slider – Demonstrates Normal, Dragging, and Disabled states with value-based interactions.
• Switch – Showcases On, Off, and Disabled states with state-based styling updates.
• Added a supporting VSMCollectionViewViewModel, providing sample data and logic for testing VisualStateManager behavior within CollectionView scenarios.

UI and Feature Coverage Enhancements

• Added interactive controls and state-triggered styling to validate VisualStateManager behavior across Entry, Button, CollectionView, CheckBox, Label, Slider, and Switch.
• Enabled users to dynamically interact with controls to verify state transitions such as:
• Normal, Selected, PointerOver, Disabled, Focused, Pressed, Checked, Unchecked, On, Off, Completed, and Dragging.
• Provided structured demonstrations to ensure consistent verification of visual state behavior across different control types and platforms.

Code-Behind and Logic
Created dedicated XAML and code-behind implementations for each VisualStateManager feature page, including interactive handlers and state-driven style logic.
Implemented a view model for CollectionView scenarios to supply sample items and support visual state testing under realistic data-binding conditions.

Issues Identified

• [Android] Adding a PointerGestureRecognizer to a button on Android stops the button from working #19289
• Multiselection for Collectionview doesn't works on MacCatalyst #18028
• CollectionView selecteditem background lost if collectionview (or parent) IsEnabled changed. #20615

Screen.Recording.2026-02-20.at.2.44.13.AM.mov

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[sheiksyedm]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

---

🤖 AI Test Quality Review — PR #34146

VSM Feature Matrix UITest Cases reviewed for coverage gaps and structural improvements.

---

🔴 Critical Issues (2)

1. All Button Tests Are Disabled on Android

Every Button test is wrapped in #if TEST_FAILS_ON_ANDROID (ref: #19289), meaning there is zero VSM coverage for Button on Android.

Tests like InitialState, Disable, and Reset are pure programmatic state changes that don't require press/release interaction. Only tests like PressedAndReleased, DisableWhilePressedAndReleased, and PressedAndReleasedWhileDisabled are actually blocked by the linked issue.

Suggestion: Move only the press-interaction tests under #if TEST_FAILS_ON_ANDROID. Programmatic-state tests should run on Android.

---

2. CollectionView Tests 16, 19, 20, 21 Are Dead Code — Disabled on ALL Platforms

#if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_IOS && TEST_FAILS_ON_CATALYST && TEST_FAILS_ON_WINDOWS
[Test, Order(16)]
public void VerifyVSM_CollectionView_DisableAndEnableWhileSelected() { ... }
// Same for Orders 19, 20, 21

These 4 tests require all four platform flags simultaneously, so they never compile on any platform. Referencing #20615.

Suggestion: Replace with [Ignore("Blocked by #20615")] so they appear as skipped in the test report and still communicate intent, or remove them until the underlying bug is fixed.

---

🟠 Structural Issues (3)

3. Tests Are Not Independently Runnable — Navigation Only in Order(1)

In every test class, Order(1) taps the gallery landing page button to navigate to the control's sub-page (e.g., App.Tap("VSMButton")). Tests with Order ≥ 2 do not re-navigate — they assume they are already on the sub-page.

If any individual test (Order ≥ 2) runs in isolation (common in CI with filtered test runs), it will immediately fail because it tries to interact with elements that don't exist on the landing page.

Suggestion: Add a [SetUp] method to handle navigation and reset, ensuring every test starts from a clean, known state:

[SetUp]
public void SetUp()
{
    App.WaitForElement("VSMButtonButton");
    App.Tap("VSMButtonButton");
    App.WaitForElement("ButtonStateLabel");
}

This applies to all 7 test classes.

---

4. Switch Tests 2 and 3 Have Implicit Sequential Dependency

VerifyVSM_Switch_On (Order 2) leaves the switch in On state. VerifyVSM_Switch_Off (Order 3) immediately taps the switch expecting it to go Off. If test 2 fails or tests run in different order, test 3 produces an incorrect result.

Suggestion: Add App.Tap("SwitchReset") at the start of test 3 to ensure a clean starting state.

---

5. GalleryPageName Constant Duplicated Across All 7 Classes

Every class independently defines:

public const string VisualStateManagerButtonFeatureTests = "VisualStateManager Feature Matrix";

The same string "VisualStateManager Feature Matrix" is duplicated 7 times.

Suggestion: Extract to a shared constant class (e.g., VSMFeatureMatrixTestConstants) to avoid typos and simplify future renames.

---

🟡 Consistency Issues (4)

6. Missing VerifyScreenshot() in Most Complex State-Transition Tests

Multi-step "compound" tests — the most valuable for catching visual regressions — often omit VerifyScreenshot():

Test	Screenshot?
VerifyVSM_Button_PressedAndReleased	✅
VerifyVSM_Button_DisableWhilePressedAndReleased	❌
VerifyVSM_Slider_DisableWhileFocused	❌
VerifyVSM_Switch_OnWhileDisableAndEnable	❌
VerifyVSM_CollectionView_DisableWhileSelected	❌

Suggestion: Each compound state-transition test should include a VerifyScreenshot() at the final verified state. These tests exist precisely because VSM visual output is what matters most.

---

7. CheckBox: Inconsistent State Names for the Same Conceptual State

• VerifyVSM_CheckBox_InitialState (Order 1) expects: "State: Unchecked"
• VerifyVSM_CheckBox_Reset (Order 3) expects: "State: Normal"

Both represent the default unchecked, enabled state — but the HostApp returns different strings depending on how you arrived there. This should be unified or clearly documented.

---

8. VerifyVSM_Label_SelectedToDisabledToNormal — Misleading Test Name

The test name implies the final state is Normal, but the actual final assertion is:

Assert.That(labelText, Is.EqualTo("State: Disabled")); // NOT Normal

The test verifies that tapping a selectable label while disabled does not change state.

Suggestion: Rename to VerifyVSM_Label_CannotSelectWhileDisabled or similar.

---

9. Entry: Inconsistent Keyboard Dismissal

Tests 6, 9, and 15–18 explicitly dismiss the keyboard via App.DismissKeyboard(), but tests like 11 (FocusedAndUnfocused) tap VSMEntry and then tap NormalEntryButton without dismissal. On Android/iOS, the keyboard may cover the button and cause a flaky failure.

Suggestion: Consistently check and dismiss the keyboard after any App.Tap("VSMEntry") call across all Entry tests.

---

🔵 Missing State Coverage (4)

10. PointerOver State Not Tested for Any Control

The PR description lists PointerOver as a supported VSM state for Button. It's also relevant for CollectionView items and Label. PointerOver can only be exercised on Mac/Windows.

Suggestion: Add tests guarded with #if MACCATALYST || WINDOWS using hover/pointer-over interactions.

---

11. Entry: Missing Completed/Returning State Test

The Entry control can expose a VSM state when the user submits via the keyboard return key. If the HostApp defines this state, a test invoking App.PressEnter() should be added.

---

12. Slider: Missing Dragging State Test

The Slider control can enter a Dragging state when the thumb is actively dragged. If the XAML style defines a Dragging state, a test using coordinate-based drag (App.DragAndDrop()) should be added to verify it.

---

13. No VisualStateManager UITest Category — Cannot Run All VSM Tests at Once

All 7 test classes use their respective control categories (Button, CheckBox, CollectionView, etc.). There is no way to filter and run all VSM Feature Matrix tests together using a single category filter.

Suggestion: Either add [Category(UITestCategories.VisualStateManager)] as a secondary attribute, or switch all classes to a shared VSM category, with control-level categories applied per test method.

---

Review performed by GitHub Copilot — automated test quality analysis of PR #34146

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[LogishaSelvarajSF4525]

Note

Are you waiting for the changes in this PR to be merged? It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

🤖 AI Test Quality Review — PR #34146

VSM Feature Matrix UITest Cases reviewed for coverage gaps and structural improvements.

🔴 Critical Issues (2)

1. All Button Tests Are Disabled on Android

Every Button test is wrapped in #if TEST_FAILS_ON_ANDROID (ref: #19289), meaning there is zero VSM coverage for Button on Android.

Tests like InitialState, Disable, and Reset are pure programmatic state changes that don't require press/release interaction. Only tests like PressedAndReleased, DisableWhilePressedAndReleased, and PressedAndReleasedWhileDisabled are actually blocked by the linked issue.

Suggestion: Move only the press-interaction tests under #if TEST_FAILS_ON_ANDROID. Programmatic-state tests should run on Android.

2. CollectionView Tests 16, 19, 20, 21 Are Dead Code — Disabled on ALL Platforms

#if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_IOS && TEST_FAILS_ON_CATALYST && TEST_FAILS_ON_WINDOWS
[Test, Order(16)]
public void VerifyVSM_CollectionView_DisableAndEnableWhileSelected() { ... }
// Same for Orders 19, 20, 21

These 4 tests require all four platform flags simultaneously, so they never compile on any platform. Referencing #20615.

Suggestion: Replace with [Ignore("Blocked by #20615")] so they appear as skipped in the test report and still communicate intent, or remove them until the underlying bug is fixed.

🟠 Structural Issues (3)

3. Tests Are Not Independently Runnable — Navigation Only in Order(1)

In every test class, Order(1) taps the gallery landing page button to navigate to the control's sub-page (e.g., App.Tap("VSMButton")). Tests with Order ≥ 2 do not re-navigate — they assume they are already on the sub-page.

If any individual test (Order ≥ 2) runs in isolation (common in CI with filtered test runs), it will immediately fail because it tries to interact with elements that don't exist on the landing page.

Suggestion: Add a [SetUp] method to handle navigation and reset, ensuring every test starts from a clean, known state:

[SetUp]
public void SetUp()
{
    App.WaitForElement("VSMButtonButton");
    App.Tap("VSMButtonButton");
    App.WaitForElement("ButtonStateLabel");
}

This applies to all 7 test classes.

4. Switch Tests 2 and 3 Have Implicit Sequential Dependency

VerifyVSM_Switch_On (Order 2) leaves the switch in On state. VerifyVSM_Switch_Off (Order 3) immediately taps the switch expecting it to go Off. If test 2 fails or tests run in different order, test 3 produces an incorrect result.

Suggestion: Add App.Tap("SwitchReset") at the start of test 3 to ensure a clean starting state.

5. GalleryPageName Constant Duplicated Across All 7 Classes

Every class independently defines:

public const string VisualStateManagerButtonFeatureTests = "VisualStateManager Feature Matrix";

The same string "VisualStateManager Feature Matrix" is duplicated 7 times.

Suggestion: Extract to a shared constant class (e.g., VSMFeatureMatrixTestConstants) to avoid typos and simplify future renames.

🟡 Consistency Issues (4)

6. Missing VerifyScreenshot() in Most Complex State-Transition Tests

Multi-step "compound" tests — the most valuable for catching visual regressions — often omit VerifyScreenshot():

Test Screenshot?
VerifyVSM_Button_PressedAndReleased ✅
VerifyVSM_Button_DisableWhilePressedAndReleased ❌
VerifyVSM_Slider_DisableWhileFocused ❌
VerifyVSM_Switch_OnWhileDisableAndEnable ❌
VerifyVSM_CollectionView_DisableWhileSelected ❌
Suggestion: Each compound state-transition test should include a VerifyScreenshot() at the final verified state. These tests exist precisely because VSM visual output is what matters most.

7. CheckBox: Inconsistent State Names for the Same Conceptual State

• VerifyVSM_CheckBox_InitialState (Order 1) expects: "State: Unchecked"
• VerifyVSM_CheckBox_Reset (Order 3) expects: "State: Normal"

Both represent the default unchecked, enabled state — but the HostApp returns different strings depending on how you arrived there. This should be unified or clearly documented.

8. VerifyVSM_Label_SelectedToDisabledToNormal — Misleading Test Name

The test name implies the final state is Normal, but the actual final assertion is:

Assert.That(labelText, Is.EqualTo("State: Disabled")); // NOT Normal

The test verifies that tapping a selectable label while disabled does not change state.

Suggestion: Rename to VerifyVSM_Label_CannotSelectWhileDisabled or similar.

9. Entry: Inconsistent Keyboard Dismissal

Tests 6, 9, and 15–18 explicitly dismiss the keyboard via App.DismissKeyboard(), but tests like 11 (FocusedAndUnfocused) tap VSMEntry and then tap NormalEntryButton without dismissal. On Android/iOS, the keyboard may cover the button and cause a flaky failure.

Suggestion: Consistently check and dismiss the keyboard after any App.Tap("VSMEntry") call across all Entry tests.

🔵 Missing State Coverage (4)

10. PointerOver State Not Tested for Any Control

The PR description lists PointerOver as a supported VSM state for Button. It's also relevant for CollectionView items and Label. PointerOver can only be exercised on Mac/Windows.

Suggestion: Add tests guarded with #if MACCATALYST || WINDOWS using hover/pointer-over interactions.

11. Entry: Missing Completed/Returning State Test

The Entry control can expose a VSM state when the user submits via the keyboard return key. If the HostApp defines this state, a test invoking App.PressEnter() should be added.

12. Slider: Missing Dragging State Test

The Slider control can enter a Dragging state when the thumb is actively dragged. If the XAML style defines a Dragging state, a test using coordinate-based drag (App.DragAndDrop()) should be added to verify it.

13. No VisualStateManager UITest Category — Cannot Run All VSM Tests at Once

All 7 test classes use their respective control categories (Button, CheckBox, CollectionView, etc.). There is no way to filter and run all VSM Feature Matrix tests together using a single category filter.

Suggestion: Either add [Category(UITestCategories.VisualStateManager)] as a secondary attribute, or switch all classes to a shared VSM category, with control-level categories applied per test method.

Review performed by GitHub Copilot — automated test quality analysis of PR #34146

I have addressed the review concerns.

• Enabled the applicable test cases and added the required snapshots for VSM Button on Android.
• Added test cases for dragging the Slider using drag coordinates and covered the Completed state for VSM Entry with the related test cases.
• Updated CollectionView tests (16, 19, 20, 21), which were dead code and disabled on all platforms, by marking them with [Ignore("Fails on all platforms")].
• Updated the UI categories for the respective VisualStateManager controls.