-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Add Wasm testing in Chromium, not just command-line v8
#40786
Add Wasm testing in Chromium, not just command-line v8
#40786
Conversation
…ASM on Windows" This reverts commit 95706be.
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @directhex |
Failures are because https://dnceng.visualstudio.com/internal/_git/dotnet-helix-machines/pullrequest/9677 hasn't landed in prod Helix instance yet. |
eng/pipelines/runtime.yml
Outdated
@@ -334,6 +334,11 @@ jobs: | |||
extraStepsParameters: | |||
creator: dotnet-bot | |||
testRunNamePrefixSuffix: Mono_$(_BuildConfig) | |||
scenarios: | |||
# Only one scenario per build for jobs which install xharness CLI | |||
# until we fix https://github.com/dotnet/arcade/issues/5919 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dotnet/arcade#5919 should be fixed now, but you might need to update the Helix SDK since Arcade wasn't released yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried bumping Arcade as part of this for testing and EVERYTHING EXPLODED so I'll wait for a bump to hit master I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@directhex bump Helix SDK, not arcade. Check the iOS draft PR and cherry pick that
This reverts commit 10243dc.
eng/testing/tests.mobile.targets
Outdated
@@ -14,7 +14,7 @@ | |||
|
|||
<PropertyGroup Condition="'$(TargetOS)' == 'Browser'"> | |||
<!-- We need to set this in order to get extensibility on xunit category traits and other arguments we pass down to xunit via MSBuild properties --> | |||
<RunScriptCommand>$HARNESS_RUNNER wasm test --engine=$(JSEngine) $(JSEngineArgs) --js-file=runtime.js -v --output-directory=$XHARNESS_OUT -- --run WasmTestRunner.dll $(AssemblyName).dll</RunScriptCommand> | |||
<RunScriptCommand>$HARNESS_RUNNER wasm test$TESTINBROWSER --app=. --engine=$(JSEngine) $(JSEngineArgs) --js-file=runtime.js -v --output-directory=$XHARNESS_OUT -- --run WasmTestRunner.dll $(AssemblyName).dll</RunScriptCommand> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'd prefer substituting the whole command rather than appending only the -browser
portion.
E.g.
<RunScriptCommand>$HARNESS_RUNNER wasm test$TESTINBROWSER --app=. --engine=$(JSEngine) $(JSEngineArgs) --js-file=runtime.js -v --output-directory=$XHARNESS_OUT -- --run WasmTestRunner.dll $(AssemblyName).dll</RunScriptCommand> | |
<RunScriptCommand>$HARNESS_RUNNER wasm $XHARNESS_COMMAND --app=. --engine=$(JSEngine) $(JSEngineArgs) --js-file=runtime.js -v --output-directory=$XHARNESS_OUT -- --run WasmTestRunner.dll $(AssemblyName).dll</RunScriptCommand> |
and then setting XHARNESS_COMMAND
to test
or test-browser
depending on Scenario.
.. on X509 certificates. Tests discovery fails on `System.Net.Http.Functional.Tests.HttpClientEKUTest..cctor()` which ends up throwing PNSE for `Certificates cctor threw System.PlatformNotSupportedException: System.Security.Cryptography.X509Certificates is not supported on this platform.` Because it's a static ctor, `SkipOnMono` will not be helpful to skip this one. So, we use `#if TARGETS_BROWSER` instead.
Should I open a separate PR for fixing |
I'd probably just add it here. |
… in the browser vs v8
…untime into add_browser_2_the_browsening
- This showed up when running System.Net.Http's FunctionalTests, as creating a listening socket fails there with `System.PlatformNotSupportedException : System.Net.Sockets is not supported on this platform.` - Also, surface the exception so it can correctly fail tests.
System.Net.Http.Functional.Tests.SyncHttpHandler_HttpClient.HandlerTest.GetAsync_InvalidUrl_ExpectedExceptionThrown
`SocketsHttpHandler_HttpClientHandlerTest`
And dotnet/xharness#313 - has some nice additions. |
|
||
if (is_browser) { | ||
// We expect to be run by tests/runtime/run.js which passes in the arguments using http parameters | ||
window.real_print = console.log; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want this in asap but after it lands I think we should consider sending all this as json over the websocket and expand it on the xharness side, we should be able to clean up the console output considerably.
pseudo code like
JSON.stringify ({ 'method': method, args: {...args}})
where method is { 'print', 'console.debug', ... }
and after that it might make sense to add a custom log provider to preserve even more structure.
|
||
consoleWebSocket = new WebSocket(consoleUrl); | ||
consoleWebSocket.onopen = function(event) { | ||
consoleWebSocket.send("browser: Console websocket connected."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a better place to force everything through print? I sometimes use runtime-tests.js outside of xharness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes sense. And I was thinking maybe the WebSocket thing should be optional? I found it useful to run the tests without the harness, directly in a browser.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is worth a follow-up once we have everything working in CI.
Update from channel - .NET Eng - Latest Updating 'Microsoft.DotNet.XHarness.CLI': '1.0.0-prerelease.20474.1' => '1.0.0-prerelease.20476.2' (from build '20200926.2' of 'https://github.com/dotnet/xharness') Updating 'Microsoft.DotNet.XHarness.TestRunners.Xunit': '1.0.0-prerelease.20474.1' => '1.0.0-prerelease.20476.2' (from build '20200926.2' of 'https://github.com/dotnet/xharness')
1 failing test remaining:
|
@radical I'm ok with skipping the last failing test. @akoeplinger Can you give this a final review to move things forward? |
@steveisok can we review System.Xml.Tests.AsyncReaderLateInitTests the for the actual browser case after this. |
@@ -941,6 +943,7 @@ public sealed class SocketsHttpHandler_SchSendAuxRecordHttpTest : SchSendAuxReco | |||
public SocketsHttpHandler_SchSendAuxRecordHttpTest(ITestOutputHelper output) : base(output) { } | |||
} | |||
|
|||
[SkipOnMono("Tests hang with chrome. To be investigated", TestPlatforms.Browser)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a tracking issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should any of the SocketsHttpHandler tests be working?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, SocketsHttpHandler should throw PNSE on wasm-browser
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's follow up on this.
Opened #42852 to discuss the loopback server problem |
This should give us a better idea of any cases where browser and JS engine behaviour diverge.