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

Make AutoCompleteResourceV3 use the supplied ILogger (if one is supplied) #4287

Merged
merged 4 commits into from Feb 15, 2022

Conversation

tintoy
Copy link
Contributor

@tintoy tintoy commented Sep 29, 2021

Otherwise fall back to NullLogger.Instance.

NuGet/Home#11272

Bug

Fixes: NuGet/Home#11272

Description

The supplied logger is now used (and, if null, then NullLogger.Instance is used; which appears to be the previous behaviour).
I'm not sure what the original intent was, but it looks to me like the logger can't be null because at least one of the downstream components created / called by the methods in question will actually throw an ArgumentNullException if passed a null logger.

PR Checklist

  • PR has a meaningful title

  • PR has a linked issue.

  • Described changes

  • Tests

    • Automated tests added
      There don't appear to be any existing tests that check if supplied loggers are used, but I'm happy to write one if you feel it is necessary.
    • OR
    • Test exception
    • OR
    • N/A
  • Documentation

    • Documentation PR or issue filled
    • OR
    • N/A

@tintoy tintoy requested a review from a team as a code owner September 29, 2021 02:27
@ghost ghost added the Community PRs created by someone not in the NuGet team label Sep 29, 2021
@@ -51,8 +51,8 @@ public AutoCompleteResourceV3(HttpSource client, ServiceIndexResourceV3 serviceI

var queryUri = queryUrl.Uri;
var results = await _client.GetJObjectAsync(
new HttpSourceRequest(queryUri, Common.NullLogger.Instance),
Copy link
Contributor

Choose a reason for hiding this comment

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

Thank you for your contribution.
Maybe ILogger logger = log ?? Common.NullLogger.Instance; then reusing it might look better. Also adding asserting logger log in following places would be great idea.
https://github.com/NuGet/NuGet.Client/blob/dev/test/NuGet.Core.Tests/NuGet.Protocol.Tests/AutoCompleteResourceV3Tests.cs
https://github.com/NuGet/NuGet.Client/blob/dev/test/NuGet.Core.Tests/NuGet.Protocol.Tests/PowershellAutoCompleteResourceTests.cs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, will do!

Copy link
Contributor

Choose a reason for hiding this comment

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

Please ping me once you make push changes.

Copy link
Contributor Author

@tintoy tintoy Sep 30, 2021

Choose a reason for hiding this comment

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

Sorry, @erdembayar - quick question:

Also adding asserting logger log in following places would be great idea.

If I understand this correctly, the test should assert that the supplied ILogger instance is used, and not NullLogger.Instance?

NullLogger is a singleton (and there doesn't seem to be any other test-friendly implementation of ILogger that I can easily create an instance of, in order to verify that the supplied ILogger instance is used rather than NullLogger.Instance).

Off the top of my head, options for this are:

  1. Use Moq's Mock<T> to mock out an ILogger (potentially tricky because I don't know what calls downstream components will make to it so it might make the test a little fragile)
  2. Create a new logger class (derived from LoggerBase) just for use in these tests
  3. Just try to get a separate instance of NullLogger to play with (eg. via Activator.CreateInstance or similar)?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would go with 2nd option. You can create new logger class implements ILogger and pass to resource and check if anything is logged into logger after operation.
If you see anything in logged then it's good.

Copy link
Member

Choose a reason for hiding this comment

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

You can create new logger class implements ILogger

We have a TestLogger.

Please uste that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I've added a logging check to the test for IdStartsWithAsync, but there isn't a test for VersionStartsWithAsync. If you're happy with the changes I made to the first test I'm happy to have a go at writing the second one.

Copy link
Contributor

Choose a reason for hiding this comment

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

Please check my comment.


// Assert
Assert.Equal(10, result.Result.Count());
Assert.NotEqual(0, logger.Messages.Count);
Copy link
Contributor

Choose a reason for hiding this comment

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

It's going correct direction. But we need some action which logs something into logger.Messages. If it's 0 then it's hard to tell if we're not logging correctly or nothing really happened.
Please try to find scenario that logs something. Currently nothing comes into my mind that logs something here.

Copy link
Contributor

Choose a reason for hiding this comment

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

@tintoy - Sorry for the delay in responding on this pull request. Looking at the code path I could not find any scenario where errors are logged to the logger. I noticed only information messages added to the logger. I am fine with the current test unless other team members have unique perspective.

Can you please modify tests in the below class file because AutoCompleteResource is also used in powershell commands?

For e.g.

public async Task PowershellAutoComplete_IdStartsWithCancelsAsAppropriate(string sourceUrl)

Please rebase your branch with dev to get latest.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No problem, sorry this one kinda dropped off my radar for a while too. Will get onto it ASAP :)

Copy link
Contributor

Choose a reason for hiding this comment

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

So far, I don't see any test which actually logging anything.
We need something not 0 and content of message is what you intended to log.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, no worries; can I assume that any of the messages currently logged (based on inspection of the code) can be considered a suitable candidate?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For what it's worth, the reason I wanted to fix this bug wasn't because of any logging done by AutoCompleteResourceV3, but because of messages logged by a downstream component (HttpSourceRequest) that AutoCompleteResourceV3 was passing NullLogger.Instance to rather than the supplied logger:

9c9846d#diff-ffa236dbba0f0c9de9e65a973bbfbee253081710ee2bf20eeab2f3a9ef51d6b8L54

I guess what I'm getting at is that the this method doesn't log anything itself, but a downstream component that it uses does, and perhaps this is what we can test for?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know any message can be logged here, but if we're adding logging then better to something logged in there to test. What is your use case? I assume you already have one, then just add test for it.

Sorry, I misread this, LGTM.

@tintoy
Copy link
Contributor Author

tintoy commented Feb 5, 2022

Hmm, I think perhaps this wasn't the rebase I was after.

@zivkan
Copy link
Member

zivkan commented Feb 5, 2022

You did a merge (commit 2a3ac2c), rather than a rebase + force push. Can you please try to fix it, as GitHub is showing all the files modified by everyone else's PRs, making it really difficult to figure out what your PR is actually changing.

@tintoy
Copy link
Contributor Author

tintoy commented Feb 6, 2022

Oops - thanks, that's what I meant to do!

Copy link
Contributor

@kartheekp-ms kartheekp-ms left a comment

Choose a reason for hiding this comment

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

👏👏👏👏

@kartheekp-ms kartheekp-ms merged commit 82e9aa3 into NuGet:dev Feb 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community PRs created by someone not in the NuGet team
Projects
None yet
5 participants