Add a couple of "stress tests" to the integration test project #11481
Conversation
There was a problem hiding this comment.
This is our normal BlazorProject that our tests use, but with two other projects in the solution. One is a Razor Class Library with a couple of components, and one is a Class Library with one class. The class library is referenced and used from both the RCL and the web project.
| max = Math.Max(max, duration); | ||
| avg = ((avg * (i - 1)) + duration) / i; | ||
| Logger.LogInformation($"**** Test iteration finished: #{i} in {TimeSpan.FromTicks(duration).TotalMilliseconds}ms"); | ||
| Logger.LogInformation($"**** Test iteration duration: min={TimeSpan.FromTicks(min).TotalMilliseconds}ms, max={TimeSpan.FromTicks(max).TotalMilliseconds}ms, avg={TimeSpan.FromTicks(avg).TotalMilliseconds}ms"); |
There was a problem hiding this comment.
Thought it would be nice to get some rough timing so we can see if things get slower over time, or even compare with and without cohosting. I'm logging it every iteration because collecting logs after an hour run seems to be a little hit and miss, so didn't want to just rely on the results being the very last thing the test did.
| await TestServices.SolutionExplorer.OpenSolutionAsync(slnFile, cancellationToken); | ||
|
|
||
| return projectFile; | ||
| return Directory.EnumerateFiles(solutionPath, $"{RazorProjectConstants.BlazorProjectName}.csproj", SearchOption.AllDirectories).Single(); |
There was a problem hiding this comment.
I know this is how it was before, but why are we enumerating for just one? Or is this to assert that there is ONLY one?
There was a problem hiding this comment.
This method did two things: Find the one "main" project we're using and return its path, and update the project file to the right TFM.
This enumeration is just the first bit, but we now also need to enumerate all of the projects to update all of the TFMs. I could have checked for this file in the other enumeration and saved it to a local but I am especially lazy in integration tests.
Noticed that we were not removing PR numbers when [fixing up the C# ext. CHANGELOG](dotnet/vscode-csharp#8071). Leaving the PR number in allows GH to turn it into a link when the number is in the range to be valid. BEFORE: * React to NuGet package pruning warnings (#11496) (PR: [#11496](dotnet/razor#11496)) * Add a couple of "stress tests" to the integration test project (#11481) (PR: [#11481](dotnet/razor#11481)) * Fix a couple of options in the old options screen (#11486) (PR: [#11486](dotnet/razor#11486)) * Don't use Directory.Exists to check if a path is relative (#11483) (PR: [#11483](dotnet/razor#11483)) * Fix another IDE0040 violation (#11474) (PR: [#11474](dotnet/razor#11474)) * Remove accessibility modifiers from interface members (#11472) (PR: [#11472](dotnet/razor#11472)) AFTER: * React to NuGet package pruning warnings (PR: [#11496](dotnet/razor#11496)) * Add a couple of "stress tests" to the integration test project (PR: [#11481](dotnet/razor#11481)) * Fix a couple of options in the old options screen (PR: [#11486](dotnet/razor#11486)) * Don't use Directory.Exists to check if a path is relative (PR: [#11483](dotnet/razor#11483)) * Fix another IDE0040 violation (PR: [#11474](dotnet/razor#11474)) * Remove accessibility modifiers from interface members (PR: [#11472](dotnet/razor#11472))
Two tests that run for an hour, adding and removing components and verifying that classification is correct afterwards. One uses an RCL, one doesn't.
The tests are setup to not run in CI, only manually on dev machines, so as not to delay the CI runs, and because sometimes these have a different version of "success" :)