[release/11.0.1xx-preview7] De-flake DragEvents UI test assertions

[kubaflo]

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!

Description

The Windows DragEvents UI test can read event-label text before queued drag/drop event updates are reflected in the accessibility tree. Build 1537359 observed DragOverEvents: instead of DragOver, while the retry passed.

Wait for each expected event value before asserting its exact text. This preserves coverage for all four drag/drop events without adding sleeps or broad test retries.

Validation

• dotnet format Microsoft.Maui.sln --no-restore --include src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs --exclude Templates/src --exclude-diagnostics CA1822
• git diff --check

[kubaflo]

/azp run

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 37045

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 37045"

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

Pull request overview

This PR aims to de-flake the DragEvents UI test by replacing immediate text reads/assertions with a helper that waits for each drag/drop event label to update before asserting exact text.

Changes:

• Refactors per-event assertions in DragEvents() into a shared AssertEventText helper.
• Introduces a wait step prior to asserting each event label’s final text value.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/TestUtils/src/UITest.Appium/HelperExtensions.cs:1114

• WaitForTextEqualToElement uses retryFrequency.Milliseconds when delaying between retries. TimeSpan.Milliseconds is only the milliseconds component (0-999), so this becomes incorrect if the retry frequency is ever changed to >= 1s (or if this code is copy/pasted elsewhere). Use the Task.Delay(TimeSpan) overload to avoid this pitfall.

				Task.Delay(retryFrequency.Milliseconds).Wait();

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:52

• AssertEventText already waits until the label text is exactly the expected value (and the helper uses the same underlying getText command). The follow-up GetText() call is redundant and can still introduce flakiness if Appium briefly errors or the accessibility snapshot changes again between the wait and the assertion. Consider relying on the wait assertion alone.

			Assert.That(
				App.WaitForTextEqualToElement(automationId, expectedText),
				Is.True,
				$"Timed out waiting for {automationId} to become '{expectedText}'.");
			Assert.That(App.FindElement(automationId).GetText(), Is.EqualTo(expectedText));

[kubaflo]

Addressed the two suppressed review nits in db0a409: WaitForTextEqualToElement now uses the Task.Delay(TimeSpan) overload (not TimeSpan.Milliseconds), and AssertEventText drops the redundant GetText() re-read since the exact-text wait already asserts the value.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/TestUtils/src/UITest.Appium/HelperExtensions.cs:1115

• WaitForTextEqualToElement uses DateTime.Now to measure elapsed time and Task.Delay(...).Wait() in a tight polling loop. Using wall-clock time can hang if the system clock moves backwards (NTP/time sync), and Task.Delay().Wait() allocates a Task each iteration. Consider switching to Stopwatch for elapsed time and Thread.Sleep for the polling delay (consistent with other wait helpers in this file).

			timeout ??= DefaultTimeout;
			TimeSpan retryFrequency = TimeSpan.FromMilliseconds(500);

			DateTime start = DateTime.Now;

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:48

• The comment says the wait "already asserts" the exact text, but WaitForTextEqualToElement returns a bool (it checks equality; the Assert.That(...) is what asserts). Tweaking the wording avoids confusion when someone reads this test later.

			// Wait for the label's text to become EXACTLY the expected value. A substring wait is
			// unreliable here because each label's placeholder (e.g. "DragOverEvents: ") already
			// contains the expected event name (e.g. "DragOver"), so a Contains-based wait would pass
			// immediately on the placeholder. The wait already asserts the exact text, so no separate
			// GetText re-read is needed (it would only re-open a window for transient Appium flakiness).

[PureWeen]

Adversarial review

Three findings survived consensus: two testing-reliability warnings and one maintainability suggestion. The exact-text comparison itself is correct: the host pages replace each placeholder with the expected bare event name, and each poll re-queries the accessibility element rather than caching it.

Methodology: 3 independent reviewers with adversarial consensus + repo domain specialist.

Test coverage: The changed DragEvents path directly exercises the new helper, but the equivalent sibling drag/drop test retains the same racy immediate-read pattern.

Prior review status: Earlier feedback about substring matching, TimeSpan.Milliseconds, and the redundant text re-read is addressed in the current head.

[kubaflo]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[kubaflo]

@PureWeen thanks for the thorough pass — addressed all three points in ae51188:

• Shared polling loop: WaitForTextToBePresentInElement and WaitForTextEqualToElement now delegate to one private predicate-based WaitForText, so they can't drift apart. This also fixed the older helper's Task.Delay(int) millisecond overload.
• Surface last observed text: the timeout diagnostic now logs the last successfully-read text plus the expected value, so a placeholder-stuck/stalled label is distinguishable from a text-read failure.
• Reuse in DragAndDropBetweenLayouts: the four event labels now wait for the exact text before reading.

Ready for another look 🙏

[kubaflo]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (4)

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:75

• After waiting with WaitForTextEqualToElement, the test re-queries the element text and asserts again. That extra GetText can reintroduce the same transient Appium/accessibility-tree flakiness this PR is trying to remove, and it’s redundant now that AssertEventText already handles the wait + assertion with a clear timeout message. Consider replacing this whole block with AssertEventText(...).

This issue also appears in the following locations of the same file:

• line 83
• line 94
• line 116

			App.WaitForTextEqualToElement("DragStartEventsLabel", "DragStarting");
			var textAfterDragStart = App.FindElement("DragStartEventsLabel").GetText();

			if (string.IsNullOrEmpty(textAfterDragStart))
			{

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:87

• Same pattern as above: WaitForTextEqualToElement already proves the label text is exactly the expected value. Re-reading with GetText and re-asserting is redundant and can reintroduce flakiness. Replace this block with AssertEventText(...).

			App.WaitForTextEqualToElement("DragOverEventsLabel", "DragOver");
			var textAfterDragOver = App.FindElement("DragOverEventsLabel").GetText();
			if (string.IsNullOrEmpty(textAfterDragOver))
			{
				Assert.Fail("Text was expected: Drag over event");

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:98

• Same issue: the wait already guarantees the expected text; the follow-up GetText/if/else is redundant and can cause flakiness if the second read returns a stale value. Replace the block with AssertEventText(...).

			App.WaitForTextEqualToElement("DragCompletedEventsLabel", "DropCompleted");
			var textAfterDragComplete = App.FindElement("DragCompletedEventsLabel").GetText();
			if (string.IsNullOrEmpty(textAfterDragComplete))
			{
				Assert.Fail("Text was expected: Drag complete event");

src/Controls/tests/TestCases.Shared.Tests/Tests/DragAndDropUITests.cs:120

• Same pattern: once WaitForTextEqualToElement is used, re-fetching the label text is redundant and risks a transient mismatch. Replace with AssertEventText(...).

			App.WaitForTextEqualToElement("DropEventsLabel", "Drop");
			var textAfterDrop = App.FindElement("DropEventsLabel").GetText();
			if (string.IsNullOrEmpty(textAfterDrop))
			{
				Assert.Fail("Text was expected: Drop event");

[kubaflo]

@PureWeen this is now proven at the current head ae51188f80: WinUI Gestures in UI build 1537896 ran DragEvents successfully (Passed DragEvents [5 s]; 198/198 tests passed in the shard). Please merge when ready.

[kubaflo]

Consolidated into #37081, which is now the single rebased test-only stabilization PR for Preview 7.