Skip to content

[Bug]: Playwright MSTest.Sdk Uses MSTest Runner, Ignoring runsettings Configuration #3124

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

Open
terius7 opened this issue Mar 9, 2025 · 2 comments

Comments

@terius7
Copy link

terius7 commented Mar 9, 2025

Version

1.50.0

Steps to reproduce

When using Playwright version 1.50.0 with MSTest.Sdk version 3.8.1, the MSTest runner is used instead of the expected VSTest runner. As a result, the Playwright configuration section in the runsettings file is ignored. Key settings such as BrowserName, ExpectedTimeout, Headless, and Channel do not work.

However, when <UseVSTest>true</UseVSTest> is explicitly set in the .csproj file, and the VSTest runner is used, the Playwright settings in the runsettings file work as expected.

Expected behavior

  • Playwright should respect the runsettings file when running tests with MSTest.Sdk.
  • Playwright-specific settings such as BrowserName, ExpectedTimeout, Headless, and Channel should be applied correctly, regardless of whether MSTest or VSTest is used.

Actual behavior

  • With MSTest runner, the Playwright settings in runsettings are ignored.
  • With VSTest runner (<UseVSTest>true</UseVSTest>), the settings work as expected.

Additional context

This issue suggests that MSTest.Sdk is defaulting to the MSTest runner instead of the VSTest runner, which does not properly load the Playwright settings from runsettings. It would be helpful if Playwright could support runsettings consistently across different test runners.

Would appreciate any insights or fixes on this issue. Thanks!

Environment

- Playwright Version: 1.50.0
- MSTest.Sdk Version: 3.8.1
- .NET Version: net8.0
@mxschmitt
Copy link
Member

mxschmitt commented Mar 10, 2025

Sounds similar to the issues we are encountering with #3093. We probably need to change how the config is getting parsed from a TestAdapter to something else. Or plumb the values through the other process somehow.

@0xced
Copy link
Contributor

0xced commented Apr 15, 2025

Sounds like another argument in favor of #3081. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants