Skip to content

Fix UseAsync property in TestMethodAttribute derived classes to use type checks #5708

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 10, 2025

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Jun 7, 2025

Summary

This PR fixes an issue where custom TestMethodAttribute derived classes were incorrectly falling back to synchronous execution instead of using their async implementations.

Problem

The TestMethodAttribute constructor sets UseAsync = GetType() == typeof(TestMethodAttribute), which evaluates to false for derived classes. However, derived classes like UITestMethodAttribute, DataTestMethodAttribute, and STATestMethodAttribute were overriding the UseAsync property to return true directly:

private protected override bool UseAsync => true;  // Problematic

This caused inconsistent behavior where the framework would fall back to the synchronous Execute method instead of using the asynchronous ExecuteAsync method that these attributes implement.

Solution

Updated all derived TestMethodAttribute classes to use the same type-checking pattern as the base class:

// Before
private protected override bool UseAsync => true;

// After  
private protected override bool UseAsync => GetType() == typeof(UITestMethodAttribute);

This ensures that:

  • Only the exact type uses the async execution path
  • Classes that derive from these attributes must explicitly opt in to async behavior
  • Behavior is consistent with the base TestMethodAttribute constructor logic

Files Changed

  • UWP_UITestMethodAttribute.cs: UseAsync now checks for exact UITestMethodAttribute type
  • WinUI_UITestMethodAttribute.cs: UseAsync now checks for exact UITestMethodAttribute type
  • DataTestMethodAttribute.cs: UseAsync now checks for exact DataTestMethodAttribute type
  • STATestMethodAttribute.cs: UseAsync now checks for exact STATestMethodAttribute type

Each change is minimal and surgical - exactly one line modified per file.

Impact

This fix ensures that custom test method attributes properly use their async execution paths, which is especially important for UI testing scenarios where execution must happen on specific threads.

Fixes #5707.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

  • 4vyvsblobprodcus361.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • 8xbvsblobprodcus382.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • bcnvsblobprodcus378.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • i1qvsblobprodcus353.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • l49vsblobprodcus358.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • mfjvsblobprodcus373.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)
  • s4uvsblobprodcus326.vsblob.vsassets.io
    • Triggering command: dotnet build src/TestFramework/TestFramework/TestFramework.csproj (dns block)

If you need me to access, download, or install something from one of these locations, you can either:


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

…ype checks

Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>
@Copilot Copilot AI changed the title [WIP] TestMethodAttribute.Execute is overridable, but ExecuteAsync is not Fix UseAsync property in TestMethodAttribute derived classes to use type checks Jun 7, 2025
@Copilot Copilot AI requested a review from Youssef1313 June 7, 2025 18:36
Copilot finished work on behalf of Youssef1313 June 7, 2025 18:36
Copy link
Member

@Youssef1313 Youssef1313 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly how I would have done it :)

@Youssef1313 Youssef1313 marked this pull request as ready for review June 7, 2025 18:38
@Youssef1313
Copy link
Member

/backport to rel/3.9

Copy link
Contributor

github-actions bot commented Jun 8, 2025

Started backporting to rel/3.9: https://github.com/microsoft/testfx/actions/runs/15515673213

@Evangelink Evangelink enabled auto-merge (squash) June 10, 2025 07:43
Evangelink pushed a commit that referenced this pull request Jun 10, 2025
…ype checks by @Copilot in #5708 (backport to rel/3.9) (#5710)

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>
@Evangelink Evangelink merged commit 881ccf3 into main Jun 10, 2025
9 checks passed
@Evangelink Evangelink deleted the copilot/fix-5707 branch June 10, 2025 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TestMethodAttribute.Execute is overridable, but ExecuteAsync is not
4 participants