Uh oh!
There was an error while loading. Please reload this page.
[wasm] Stop testing with V8 and wasmconsole - #108711
Conversation
…itance, clean the code.
Tagging subscribers to 'arch-wasm': @lewing |
| BuildTemplateProject(buildArgs, id: id, new BuildProjectOptions( | ||
| AssertAppBundle: false, | ||
| CreateProject: false, | ||
| HasV8Script: false, |
There was a problem hiding this comment.
V8Script could be dropped too. I expect it would many more places than just WBT. Could be in next PR
| AssertSymbolsFile: false // FIXME: not supported yet | ||
| )); | ||
| public override string FindBinFrameworkDir(string config, bool forPublish, string framework, string? projectDir = null) |
There was a problem hiding this comment.
Why do we need to override it here? Blazor and Wasm SDK should behave the same
There was a problem hiding this comment.
That's true, originally I didn't notice they are the same, it can be left in WasmSdkBasedProjectProvider only.
Note for the future: once we will align BlazorBuildOptions and AssertWasmSdkBundleOptions then maybe we will even use WASM SDK provider in Blazor and drop BlazorWasmProjectProvider.
Uh oh!
There was an error while loading. Please reload this page.
| public class DebugLevelTests : AppTestBase | ||
| { | ||
| public DebugLevelTests(ITestOutputHelper output, SharedBuildPerTestClassFixture buildContext) |
There was a problem hiding this comment.
I think we should merge this one with Wasm.Build.Tests.DebugLevelTests and use "WasmBasicTestApp" for all of the tests.
- Move it outside of Blazor namespace since it's not blazor specific
There was a problem hiding this comment.
It was not done because it would require more refactoring. In the feedback commit I moved them to one file and made them use WasBasicTestApp but it broke the base class, now it's DebugLevelTests : AppTestBase. Will be cleaned up better in a follow-up
| TargetFramework: BuildTestBase.DefaultTargetFramework, | ||
| UseCache: false, | ||
| IsBrowserProject: isBrowser, | ||
| IsBrowserProject: true, |
There was a problem hiding this comment.
I think we can remove IsBrowserProject or similar if we have any
There was a problem hiding this comment.
Not yet. We have a significant bundle assert check that based on its value uses either the wasm sdk-like way assert or deprecated but still used by tests (to be removed in a follow up) mainJs-like assert. This would lead to too many other changes. Later
There was a problem hiding this comment.
Since everything is now Wasm SDK, I think we can remove this base class
There was a problem hiding this comment.
Yes, it can be removed in the follow up that will be getting rid of TestMainJsProjectProvider that is still based on ProjectProviderBase and used in ~16 test files.
Follow up for #108582 (comment).
wasmconsoleinWasmBuildTests. Some tests were using console scenario but did not mean to target specifically console, so they had to stay but be changed to usebrowserwasm. This revealed a bunch of inconsistencies that required refactoring. I will try to list the biggest refactoring changes in the following points.WasmTemplateTestBaseandWasmTemplateTestsBasethat in fact could be consolidated in one class.NativeBuildTests <- WasmTemplateTestBase <- BlazorWasmTestBase <- WasmTemplateTestsBase <- BuildTestBaseThis was refactored to have blazor and browser apps in 2 logical "flows", e.g.:
WorkloadRequiredTests <- BlazorWasmTestBase <- WasmTemplateTestsBase <- BuildTestBaseNativeBuildTests <- WasmTemplateTestsBase <- BuildTestBaseRunCommandandToolCommanddirectly in the tests. Theye were exchanged for wrappers. For build/publish action we should useBuildTemplateProjectand for running the browser app,RunBrowser. It is supposed to get merged with Blazor-based runners in a follow up PR, it will take too many changes to do it here.!(buildArgs.AOT || buildArgs.Config == "Release")a lot, so it got closed inIsDotnetWasmFromRuntimePack.BuildProjectOptions, so we will have a "base" form of options (_basePublishProjectOptions,_baseBuildProjectOptions) that we can extend in the specific test but most frequently we use them in the default form.The issues that were discovered when refactoring will be temporarily marked as "Issue" in the comment, then if not fixed, they will be logged as separate issues in the repo.
Follow-up PRs that will be published after this one is done:
[BuildAndRun(that creates a console app (withMicrosoft.NET.Sdk), we should use templating mechanism. We still have ~40 tests that do not use templates.AppTestBase,TestMainJsTestBase,TestMainJsProjectProviderand consolidate running methods fromAppTestBaseandWasmTemplateTestsBase, so tests derive fromWasmTemplateTestsBaseif they are browser apps and fromBlazorWasmTestBaseif they are blazor apps, nothing more. Clean up option records,BuildProjectOptions,BlazorRunOptions,BlazorBuildOptionsetc.