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 unit tests to validate cohosting configuration #11151

Merged
merged 6 commits into from
Nov 5, 2024

Conversation

davidwengier
Copy link
Contributor

These tests detect an issue I ran into doing code actions, and Dustin ran into doing hover.

Also makes it impossible to forget to specify a DocumentSelector in a registration.

@davidwengier davidwengier requested a review from a team as a code owner November 5, 2024 03:51
Copy link
Contributor

@ryzngard ryzngard left a comment

Choose a reason for hiding this comment

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

I'm definitely not an expert here but it looks reasonable to me

{
if (endpoint is CohostSemanticTokensRangeEndpoint)
{
// We can't currently test this, as the GetRegistrations method calls requestContext.GetRequiredService
Copy link
Contributor

Choose a reason for hiding this comment

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

What about a Mock?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can't mock structs, and RazorCohostRequestContext is a struct, which takes a roslyn RequestContext as a constructor parameter, which is also a struct :)

Copy link
Contributor

Choose a reason for hiding this comment

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

ah I missed it was a struct!


foreach (var registration in registrations)
{
var options = registration.RegisterOptions as ITextDocumentRegistrationOptions;
Copy link
Contributor

Choose a reason for hiding this comment

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

💭I'm not sure what the error message looks like but there is Assert.IsType<T>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All of the standard failure messages look terrible IMO and I hate that xunit got rid of the message parameters from most of them. In this case it would be something like "IsType failed, expected ITextDocumentRegistrationOptions", so you'd have to just debug the test to find out which one was the problem.

Copy link
Contributor

Choose a reason for hiding this comment

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

Tyme to start writing extension methods for ALL of XUnit :P

Copy link
Member

Choose a reason for hiding this comment

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

Not sure that'd work out, since xUnit's Assert is a static class and we don't have the ability to create static extension methods. IMO, we'd be better off just using FluentAssertions or some other library.

Copy link
Contributor

Choose a reason for hiding this comment

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

Or do the AssertEx thing for our own implementations

@davidwengier davidwengier disabled auto-merge November 5, 2024 22:17
@davidwengier davidwengier merged commit fe32865 into dotnet:main Nov 5, 2024
11 of 12 checks passed
@davidwengier davidwengier deleted the CohostEndpointTests branch November 5, 2024 23:31
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Nov 5, 2024
@jjonescz jjonescz modified the milestones: Next, 17.13 P2 Nov 25, 2024
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.

4 participants