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

Use dotnet test #48686

Merged
merged 5 commits into from
Oct 20, 2020
Merged

Use dotnet test #48686

merged 5 commits into from
Oct 20, 2020

Conversation

jaredpar
Copy link
Member

@jaredpar jaredpar commented Oct 16, 2020

This change is migrating us away from the xUnit console runner and onto
the dotnet test command instead. This has the following advantages:

  1. xunit console runner is not a supported product hence we really need to move off it anyways.
  2. Can take advantage of all the crash dump and blame analysis that they are doing in the dotnet test tool
  3. Simplifies our story a bit because it means we are dealing with a single way to invoke tests across all the different configurations, OS we run. It's dotnet test all the time. This is true even when we are running .NET Framework tests.
  4. One step closer to removing all of the restore logic from our test jobs

This change is migrating us away from the xUnit console runner and onto
the `dotnet test` command instead.
@Dotnet-GitSync-Bot
Copy link
Collaborator

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.

@@ -266,5 +266,7 @@
rather explicitly override it.
-->
<UsingToolMicrosoftNetCompilers Condition="'$(BootstrapBuildPath)' == ''">true</UsingToolMicrosoftNetCompilers>

<UseVSTestRunner>true</UseVSTestRunner>
Copy link
Contributor

Choose a reason for hiding this comment

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

do we also need to update MicrosoftNETTestSdkVersion in this file?

Copy link
Member Author

Choose a reason for hiding this comment

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

What relationship does that have to how the tests run here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I had the impression that Microsoft.Net.Test.Sdk actually controls what version of the test host gets loaded and that updating it is required to e.g. benefit from the change that makes the test host actually multi-target (or whatever was blocking us from moving to dotnet test before).

@jaredpar jaredpar marked this pull request as ready for review October 19, 2020 20:15
@jaredpar jaredpar requested review from a team as code owners October 19, 2020 20:15
@jaredpar
Copy link
Member Author

@dotnet/roslyn-infrastructure PTAL

@RikkiGibson RikkiGibson self-assigned this Oct 19, 2020
Copy link
Contributor

@RikkiGibson RikkiGibson left a comment

Choose a reason for hiding this comment

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

LGTM with some comments and nits

{
var traits = Options.Trait.Split(new char[] { ';' }, StringSplitOptions.RemoveEmptyEntries);
foreach (var trait in traits)
void MaybeAddSeparator(char separator = '|')
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use the camelCase local function naming convention.

Copy link
Member

Choose a reason for hiding this comment

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

I believe the naming style for this directory is configured for PascalCase

Copy link
Member Author

Choose a reason for hiding this comment

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

This directory is PascalCased yes.

We need to flip the repo to be consistent here now that .NET runtime came out with their recomendations so we can avoid this in the future.

@@ -39,6 +39,7 @@ internal static class ReferenceLocationExtensions
AddSymbols(semanticModel, documentGroup, result);
}

// Keep compilation alive so that GetSemanticModelAsync remains cheap
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this intended to be included by this PR?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. Just a comment update based on an investigation I did while looking at some of the test runs.

builder.AppendFormat(@"""{0}""", assemblyInfo.AssemblyPath);
builder.AppendFormat(@" {0}", assemblyInfo.ExtraArguments);
builder.AppendFormat($@" -xml ""{xmlResultsFilePath}""");
builder.Append($@"test");
Copy link
Contributor

Choose a reason for hiding this comment

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

might be worth commenting that this is about coming up with arguments to dotnet CLI in order to run this partition's tests, I had to blink at this for a sec to remember why we were passing the bare string "test" as a command line argument.

@@ -266,5 +266,7 @@
rather explicitly override it.
-->
<UsingToolMicrosoftNetCompilers Condition="'$(BootstrapBuildPath)' == ''">true</UsingToolMicrosoftNetCompilers>

<UseVSTestRunner>true</UseVSTestRunner>
Copy link
Contributor

Choose a reason for hiding this comment

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

I had the impression that Microsoft.Net.Test.Sdk actually controls what version of the test host gets loaded and that updating it is required to e.g. benefit from the change that makes the test host actually multi-target (or whatever was blocking us from moving to dotnet test before).

@jaredpar
Copy link
Member Author

@sharwell do we need to look at the integration test here? Seems like a known issue.

@sharwell
Copy link
Member

@jaredpar Second run hit a variation of the bug I mostly worked around with 6b43c88. Third run hit #48548. First run hit both of these plus a lower-priority flaky test that doesn't fail the double-pass often.

@jaredpar
Copy link
Member Author

@sharwell so are we good to merge or do we need to retry again?

@sharwell
Copy link
Member

@jaredpar looks good to me

@jaredpar jaredpar merged commit 83e4631 into dotnet:master Oct 20, 2020
@ghost ghost added this to the Next milestone Oct 20, 2020
@jaredpar jaredpar deleted the dntest branch October 20, 2020 19:32
@jaredpar
Copy link
Member Author

image

jaredpar added a commit to jaredpar/roslyn that referenced this pull request Oct 21, 2020
The retry mechanism on integration tests is predicated on not having the
`--html` option passed to RunTests. PR dotnet#48686 changed it to be
unconditionally passed which ended up breaking retry. Undoing the
unconditional passing of `--html` to fix retry.
jaredpar added a commit that referenced this pull request Oct 21, 2020
* Restore retry on integration tests

The retry mechanism on integration tests is predicated on not having the
`--html` option passed to RunTests. PR #48686 changed it to be
unconditionally passed which ended up breaking retry. Undoing the
unconditional passing of `--html` to fix retry.
@allisonchou allisonchou modified the milestones: Next, 16.9.P2 Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants