Skip to content
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

[wasm][tests][browser] Http - FunctionalTests - mark failing tests #42866

Merged
merged 3 commits into from
Oct 11, 2020

Conversation

radical
Copy link
Member

@radical radical commented Sep 29, 2020

  • Most of these are failing due to LoopbackServer (PNSE)
  • some others are due to monitors not being supported (PNSE)

This brings the result to zero failures:

Tests run: 439, Errors: 0, Failures: 0, Skipped: 18. Time: 2.128495s

@radical
Copy link
Member Author

radical commented Sep 29, 2020

I'm not sure how to change this
[assembly: ActiveIssue("https://github.com/dotnet/runtime/issues/131", TestRuntimes.Mono)] (https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Http/tests/FunctionalTests/AssemblyInfo.cs#L7)
.. to enable the tests for the browser, and skip for rest of mono scenarios.

@lewing
Copy link
Member

lewing commented Sep 29, 2020

I'm not sure how to change this
[assembly: ActiveIssue("https://github.com/dotnet/runtime/issues/131", TestRuntimes.Mono)] (https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Http/tests/FunctionalTests/AssemblyInfo.cs#L7)
.. to enable the tests for the browser, and skip for rest of mono scenarios.

Hmmm, good question.

Thanks for going through these, I think we should probably annotate some of them slightly differently. I'll make a pass through.

@lewing lewing marked this pull request as draft September 29, 2020 22:58
@lewing lewing added the arch-wasm WebAssembly architecture label Oct 5, 2020
@lewing lewing force-pushed the wasm-http-fn-tests-zero-fail branch from 65c6974 to b476bdd Compare October 5, 2020 05:13
@lewing
Copy link
Member

lewing commented Oct 5, 2020

@steveisok thoughts on what we should do about enabling these in the normal flow for Browser?

@lewing lewing marked this pull request as ready for review October 5, 2020 05:17
@steveisok
Copy link
Member

steveisok commented Oct 7, 2020

You can add something like we do for System.Threading.Tasks:

[ActiveIssue("https://github.com/dotnet/runtime/issues/35916", typeof(PlatformDetection), nameof(PlatformDetection.IsMonoInterpreter), nameof(PlatformDetection.IsNotBrowser))]

Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

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

Looks good, we really need better functional tests for browser.

@lewing
Copy link
Member

lewing commented Oct 9, 2020

Selenium error

ChromeDriver was started successfully.
[04:58:49] crit: OpenQA.Selenium.WebDriverException: unknown error: Chrome failed to start: exited abnormally.
                   (chrome not reachable)
                   (The process started from chrome location /home/helixbot/work/A74B096B/p/chrome-linux/chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
                    at OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response errorResponse)
                    at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
                    at OpenQA.Selenium.Remote.RemoteWebDriver.StartSession(ICapabilities desiredCapabilities)
                    at OpenQA.Selenium.Remote.RemoteWebDriver..ctor(ICommandExecutor commandExecutor, ICapabilities desiredCapabilities)
                    at OpenQA.Selenium.Chromium.ChromiumDriver..ctor(ChromiumDriverService service, ChromiumOptions options, TimeSpan commandTimeout)
                    at OpenQA.Selenium.Chrome.ChromeDriver..ctor(ChromeDriverService service, ChromeOptions options, TimeSpan commandTimeout)
                    at Microsoft.DotNet.XHarness.CLI.Commands.Wasm.WasmTestBrowserCommand.GetChromeDriver() in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/WASM/Browser/WasmTestBrowserCommand.cs:line 90
                    at Microsoft.DotNet.XHarness.CLI.Commands.Wasm.WasmTestBrowserCommand.InvokeInternal(ILogger logger) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/WASM/Browser/WasmTestBrowserCommand.cs:line 53
                    at Microsoft.DotNet.XHarness.Common.CLI.Commands.XHarnessCommand.Invoke(IEnumerable`1 arguments) in /_/src/Microsoft.DotNet.XHarness.Common/CLI/Commands/XHarnessCommand.cs:line 120

radical and others added 3 commits October 9, 2020 15:05
- Most of these are failing due to LoopbackServer
- some others are due to monitors not being supported

This brings the result to zero failures:

`Tests run: 439, Errors: 0, Failures: 0, Skipped: 18. Time: 2.128495s`
@lewing lewing force-pushed the wasm-http-fn-tests-zero-fail branch from 81c4ee7 to fbd13ef Compare October 9, 2020 20:08
@lewing
Copy link
Member

lewing commented Oct 11, 2020

Failure is runtime (Libraries Test Run release coreclr Windows_NT x86 Debug) Cancelled after 150m

@lewing lewing merged commit 921db35 into dotnet:master Oct 11, 2020
@radical radical deleted the wasm-http-fn-tests-zero-fail branch October 12, 2020 06:25
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants