[tests] workload tests for test project templates#4240
[tests] workload tests for test project templates#4240radical merged 13 commits intomicrosoft:mainfrom
Conversation
4dd5cee to
c7364bc
Compare
|
@DamianEdwards the xunit test file in the template seems to be broken. I think this should fix it. The test failures: https://dev.azure.com/dnceng-public/public/_build/results?buildId=708682&view=ms.vss-test-web.build-test-results-tab |
842b3c1 to
e914e75
Compare
``` ... testroot/aspire-aspire-xunit/aspire-aspire-xunit.aspire-xunitTests/IntegrationTest1.cs(21,27): error CS1061: 'IServiceCollection' does not contain a definition for 'ConfigureHttpClientDefaults' and no accessible extension method 'ConfigureHttpClientDefaults' accepting a first argument of type 'IServiceCollection' could be found (are you missing a using directive or an assembly reference?) [/datadisks/disk1/work/B74F0975/t/testroot/aspire-aspire-xunit/aspire-aspire-xunit.aspire-xunitTests/aspire-aspire-xunit.aspire-xunitTests.csproj] ```
…e produced. Useful for local builds
e914e75 to
ee6ed0a
Compare
| } | ||
|
|
||
| var files = Directory.EnumerateFiles(SourceDirectory, "*.csproj", SearchOption.AllDirectories); | ||
| PackageNames = files.Where(f => File.ReadAllText(f).Contains("<IsPackable>true</IsPackable>")) |
There was a problem hiding this comment.
This would break if we move the IsPackable to a Directory.Build.props file, right? I wonder if instead of using an inline task if it's best to just use MSBuild task for all of these projects and call a target that just returns the value of IsPackable. We don't have to do it that way but I just think that would probably be more future proof and resilient against refactorings.
There was a problem hiding this comment.
Thanks for the suggestion! Changed.
joperezr
left a comment
There was a problem hiding this comment.
Left couple of suggestions, but looks good otherwise.
|
|
||
| <!-- check against an arbitrary minimum limit to catch any issues getting the list of packages --> | ||
| <Error Text="Too few packages? count: @(ExpectedPackageNames->Count())" | ||
| Condition="@(ExpectedPackageNames->Count()) < 60" |
There was a problem hiding this comment.
We are already shipping over 60 packages from this repo? Wow.
| // ActiveIssue for windows: https://github.com/dotnet/aspire/issues/4555 | ||
| yield return "aspire_龦唉丂荳_㐁ᠭ_ᠤསྲིདخەلꌠ_1ᥕ"; | ||
| } | ||
|
|
||
| // ActiveIssue: https://github.com/dotnet/aspire/issues/4550 | ||
| // yield return "aspire sta-rter.test"; // Issue: two spaces | ||
|
|
||
| yield return "aspire_starter.1period then.34letters"; | ||
| yield return "aspire-starter & with.1"; | ||
|
|
||
| // ActiveIssue: https://github.com/dotnet/aspnetcore/issues/56277 | ||
| // yield return "aspire_😀"; |
There was a problem hiding this comment.
Wow - this is catching a lot of bugs. 😄
There was a problem hiding this comment.
I think falls under "naming is one of the hardest problems in computer science" right? 😉
There was a problem hiding this comment.
For the curious this might be a bug in the template engine - dotnet/sdk#41667 !
|
|
||
| if (inTest && CommentLineRegex().IsMatch(line)) | ||
| { | ||
| sb.AppendLine(CommentLineRegex().Replace(line, " ")); |
There was a problem hiding this comment.
Hopefully we don't ever add real comments to the code, or else this would start failing.
There was a problem hiding this comment.
Lol! Yeah, but that would cause a failure on the PR, and then that person gets to figure it out :/
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
.. packable, instead of a custom task. Doing this instead of a custom task looking for a `<IsPackable>true</IsPackable>` string is better because it would not be affected by refactorings, or the property being set elsewhere. Suggestion from @jopererz .
aspire-xunit,aspire-nunit, andaspire-mstest.aspire-startertemplate with the various project namesusingin the test cs file, fixed hereMicrosoft Reviewers: Open in CodeFlow