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

Add some checks for merged test groups #89521

Merged
merged 22 commits into from
Jul 28, 2023
Merged

Conversation

markples
Copy link
Member

@markples markples commented Jul 26, 2023

  • CLRTest.Execute.Batch.targets
    • Fix CLRTestExecutionArguments (allows passing a filter argument to .cmd
    • Fix indenting in generated script
  • XUnitWrapperGenerator
    • Move some generated code into (shared) ITestInfo.cs
    • Also display exception on stdout on failure
    • Add check that projects in merged test groups don't contain entry points
      • Can be a sign of code that is expected to run but won't be
      • Or can be a [Fact]/etc-less entry point in a ReqProcIso project but would then need to be fixed if ReqProcIso were removed
  • Directory.Build.targets
    • Run XUnitWrapperGenerator on test projects in merged groups
    • Can't simply replace the conditional because we have XUnit-style tests outside of merged groups
  • Update tests to conform to above checks plus a bit of opportunistic cleanup

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jul 26, 2023
@ghost ghost assigned markples Jul 26, 2023
@ghost
Copy link

ghost commented Jul 26, 2023

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author: markples
Assignees: markples
Labels:

area-CodeGen-coreclr

Milestone: -

return 101;
}
public static void TestEntryPoint()
=> Assert.Throws<DivideByZeroException>(() => Test(0));
Copy link
Member

@jakobbotsch jakobbotsch Jul 26, 2023

Choose a reason for hiding this comment

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

The general problem I have with these assert helpers is that they expand into a ton of unrelated code that I prefer not to see when I'm looking at the test. I stopped using these generally in JIT tests when I had to skip past tons of inlined Assert.Equals gunk while investigating a test at some point.

It's probably ok for this test since most interesting stuff goes on inside Test.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the feedback. This is interesting as I've had the opposite experience when looking at the source code (rather than debugging them) in that there is so much boilerplate in the way. That said, I don't plan on widespread changes to call Equals a bunch but just happened to notice how much boilerplate was needed for Throws while auditing recent test changes. I also came to the conclusion that Throws was "less" than Equals and friends.

It would be nice to have a helper that addresses both sides. I wonder if the xunit folks would accept NoInlining everywhere. Alternatively, we could build our own wrapper library, though it would be unfortunate to end up "not standard".

(Kind of related - [Theory] often ends up not saving much over a wrapper [Fact] method since you often end up needing to pass the expected output and explicitly check against it anyway. It would be nice to have the expected return in the [InlineData]/etc., but again it wouldn't be standard.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's also interesting how often tests define their own AssertEquals, etc.!


return 100;
public static void TestEntryPoint()
Copy link
Member

Choose a reason for hiding this comment

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

Fact? Also, Task.Run(TestTask) should presumably be Task.Run(TestTask).Wait().

Copy link
Member Author

Choose a reason for hiding this comment

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

thanks - fixed

@markples
Copy link
Member Author

@trylek @jkoritzinsky This starts to add some checks to avoid mistakes in our tests. PTAL - feedback especially welcome on how to do things better with Roslyn!
cc @dotnet/jit-contrib

upcoming - #89550, #89554, and possibly other things that we find to check

@markples markples marked this pull request as ready for review July 27, 2023 19:07
Comment on lines 185 to 191
new DiagnosticDescriptor(
"XUW1001",
"No explicit entry point",
"Projects in merged tests group should not contain entry points",
"XUnitWrapperGenerator",
DiagnosticSeverity.Warning,
isEnabledByDefault: true),
Copy link
Member

Choose a reason for hiding this comment

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

We should save this in a static readonly field (makes it easier to know which diagnostic ids are in use).

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks. just fyi - I also noticed that I was generating SimpleRunners for all tests now and restricted the actual wrapper generation to ConsoleApplications (hopefully nothing is depending on libraries having entry points). I think I will run outerloop+extraplatforms to verify.

@markples
Copy link
Member Author

/azp run runtime-coreclr outerloop, runtime-extra-platforms

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@markples
Copy link
Member Author

runtime is clean. outerloop and extraplatforms seem to be #89545, #88808, and completely unrelated jobs

@markples markples merged commit 6f27090 into dotnet:main Jul 28, 2023
181 of 211 checks passed
@@ -133,8 +140,10 @@ public void WriteFooterToTempLog(StreamWriter tempLogSw)
var result = new TestResult(name, containingTypeName, methodName, duration, null, null, output);
_testResults.Add(result);

outTw.WriteLine($"{0:HH:mm:ss.fff} Passed test: {1}", System.DateTime.Now, name);
Copy link
Member

Choose a reason for hiding this comment

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

@markples This line results in printing "HH:mm:ssfff Passed test: 1" always -- presumably it shouldn't be a string interpolation.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, that's leftover from the original

builder.AppendLine($"System.Console.WriteLine(\"{{0:HH:mm:ss.fff}} Running test: {{1}}\", System.DateTime.Now, {test.TestNameExpression});");

but was for the outer level. It's weird though; I thought that I looked at the output.

@ghost ghost locked as resolved and limited conversation to collaborators Sep 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants