Improve a test in Common.Certificates

[TimHess]

Description

Wrap RegisterChangeCallback in usings, reset changeCalled boolean between changes

Fixes #1506

Quality checklist

• [x] Your code complies with our Coding Style.
• [x] You've updated unit and/or integration tests for your change, where applicable.
• [ ] You've updated documentation for your change, where applicable. If your change affects other repositories, such as Documentation, Samples and/or MainSite, add linked PRs here.
• [x] There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.
• [x] You've added required license files and/or file headers (explaining where the code came from with proper attribution), where code is copied from StackOverflow, a blog, or OSS.

[bart-vmware]

This is still wrong. Try debugging through it:

The changeCalled variable is set to true before the files get written.

[bart-vmware]

Should probably dispose X509Certificate2 instances in tests.

[bart-vmware]

Wouldn't it be easier to test via OptionsMonitor, such as in the test ChangeConfiguration_AppliesChanges, combined with MemoryFileProvider, such as in the test Reloads_options_on_change? Then the sleeps can be removed.

[TimHess]

Wouldn't it be easier to test via OptionsMonitor, such as in the test ChangeConfiguration_AppliesChanges, combined with MemoryFileProvider, such as in the test Reloads_options_on_change? Then the sleeps can be removed.

I'm not sure it's worth the effort, or exactly how we would use TestOptionsMonitor in this situation when we are also depending on IConfigureNamedOptions to read the certificate from disk, and there's code in there to exit early if the certificate is not null (which it is unless we do something to null it out).

I do like the idea of using MemoryFileProvider, but the problem is that FilePathInOptionsChangeTokenSource depends on the private class FileSystemChangeWatcher which only works with PhysicalFilesWatcher. I see an option on PhysicalFilesWatcher to pass in a FileSystemWatcher, but that still seems to be tied to a physical file system (all the tests are using TempDirectory rather than any form of in-memory option), so I'm not sure how to change this without adding some additional abstraction to wrap PhysicalFilesWatcher

[bart-vmware]

I do like the idea of using MemoryFileProvider, but the problem is that FilePathInOptionsChangeTokenSource depends on the private class FileSystemChangeWatcher which only works with PhysicalFilesWatcher. I see an option on PhysicalFilesWatcher to pass in a FileSystemWatcher, but that still seems to be tied to a physical file system (all the tests are using TempDirectory rather than any form of in-memory option), so I'm not sure how to change this without adding some additional abstraction to wrap PhysicalFilesWatcher

Good point, I didn't realize that limitation. It's unfortunate that we can't use MemoryFileProvider due to that, but I don't think it can be easily solved, so I'm okay with the original approach.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud