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 non-strict search flag for legacy unit test providers #64375

Merged
merged 2 commits into from
Sep 30, 2022

Conversation

CyrusNajmabadi
Copy link
Member

This is useful as not all test providers are written with a high degree of quality wrt to the data they produce. This allows our search service to first be called in strict mode to look for precise matches, but then be called in a more relaxed mode of none are found.


private UnitTestingSearchQuery(string fullyQualifiedTypeName, string? methodName, int methodArity, int methodParameterCount)
private UnitTestingSearchQuery(string fullyQualifiedTypeName, string? methodName, int methodArity, int methodParameterCount, bool strict)
Copy link
Contributor

Choose a reason for hiding this comment

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

One other thing we care about is presence of attributes on the method. Is it possible to introduce a flag to filter out methods that don't have any attributes? (Or perhaps hard code to exclude non-attributed methods when strict is true)

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. i'll find a way to add those smarts in.

Copy link
Contributor

@shyamnamboodiripad shyamnamboodiripad left a comment

Choose a reason for hiding this comment

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

👍🏾 lgtm modulo comments

if (query.Strict && info.TypeParameterCount != symbolArity)
continue;

if (info.Name != symbolName)
Copy link
Contributor

Choose a reason for hiding this comment

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

For VB the name could theoretically be different case. Is it possible to take that into account here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually never-mind, we'll probably require that the supplied name should match the casing present in the code in such cases. But one potential option may be to allow different casing for VB when strict is false.

Copy link
Member Author

Choose a reason for hiding this comment

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

that seems like it would be very odd for the name to not match. but sure, i can add that :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yup doing that with strict=true would certainly be odd. But it would be nice to find closest match with strict=false :)

Note that I am only proposing with behavior when strict=off and also only when the language is VB :)

}

// Looking promising so far. Check that the container matches what the caller needs.
if (info.FullyQualifiedContainerName != container)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same question about case sensitivity for VB

Copy link
Member Author

Choose a reason for hiding this comment

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

yup. i'll find a way to handle that.

@CyrusNajmabadi CyrusNajmabadi merged commit 460dc7b into dotnet:main Sep 30, 2022
@ghost ghost added this to the Next milestone Sep 30, 2022
@CyrusNajmabadi CyrusNajmabadi deleted the nonStrictFlag branch September 30, 2022 15:52
@RikkiGibson RikkiGibson modified the milestones: Next, 17.5 P1 Oct 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants