Added WSMan Config provider tests#4756
Conversation
0792984 to
5480257
Compare
There was a problem hiding this comment.
Should we wait that the service stop?
There was a problem hiding this comment.
Stop-Service should be waiting by default, it has a -nowait switch
There was a problem hiding this comment.
Do we want have all tab complete tests in one file TabCompletion.Tests.ps1?
There was a problem hiding this comment.
Why the Should in finally block? Maybe add a comment?
There was a problem hiding this comment.
The tests are for new-item and corresponding remove-item. Should validates that the remove-item worked. The test title indicates this and I thought was obvious enough. In case some other Should validation fails before the remove-item I still want to cleanup. Do you think a comment is needed?
There was a problem hiding this comment.
Thanks for clarify.
Closed.
There was a problem hiding this comment.
Should we move the test to a file with all Help tests? Tum more what we want to move Help subsystem in separate module.
There was a problem hiding this comment.
This test is a bit different from the HelpSystem.Tests.ps1 as it's testing the implementation of ICmdletProviderSupportsHelp in this provider (not testing the HelpSystem). But more than that, it's specific to Windows and requires elevation.
There was a problem hiding this comment.
Thanks for clarify. I think we should mention ICmdletProviderSupportsHelp in a comment or Context description.
There was a problem hiding this comment.
Microsoft.powershell is the Windows PowerShell endpoint. Ideally, PowerShell Core should work with the PowerShell Core endpoint as its template. It would require a call to Enable-PSRemoting within PowerShell Core to set up.
There was a problem hiding this comment.
I'll make the change
There was a problem hiding this comment.
Had to change it back as using Install-PowerShellRemoting or Enable-PSRemoting was making things complicated even though my tests had no dependency on remoting actually working. Since I'm just relying on a well known existing plugin configuration, I think using microsoft.powershell seems reasonable.
There was a problem hiding this comment.
Should this user be added to the Administrators group?
There was a problem hiding this comment.
Not needed, I don't do any actual remoting. I just need a valid local account to set configuration (runas)
There was a problem hiding this comment.
Please use more descriptive variable names
There was a problem hiding this comment.
Would it be useful to also test that it resolves ambiguous parameters in a consistent manner? "-pr" and "-pl" collide at "-p".
There was a problem hiding this comment.
There should already be tabcomplete tests to cover that. This is specifically testing WSMan Config Provider's returning dynamic parameters
There was a problem hiding this comment.
Out of curiosity, where did these SDDL values come from?
There was a problem hiding this comment.
I'll add a comment, but the second one is the default SDDL, the first is a truncated version
There was a problem hiding this comment.
I'm starting to see patterns here among the tests. I like the descriptive names of the It's, but I'm wondering if they can be combined as TestCases to include the path to the property as well as the property and value. A change isn't necessarily required, but I'm curious if you considered it.
There was a problem hiding this comment.
I thought about it while writing the tests, but there's enough differences in the properties and validation I think it would be overly complicated to combine them
There was a problem hiding this comment.
This is the Windows PowerShell plugin path. It matches the config you have been using throughout, but it will need to be updated
There was a problem hiding this comment.
I'll update it to the one for PSCore6
There was a problem hiding this comment.
We should not use "foo" and "bar" since they violate PolyCheck. Please use other string values.
There was a problem hiding this comment.
I believe policheck allows it for code, but not in strings given to users. In any case, if we need to fix this, we should have a separate PR for all the code.
There was a problem hiding this comment.
Does Remove-Item on a non-existant path throw an error?
There was a problem hiding this comment.
I'm testing Remove-Item and also trying to cleanup. I think it may be better since @iSazonov gave similar feedback and have some redundancy where I do the remove-item test within the try and still do cleanup.
39133cf to
833984d
Compare
|
CI failure waiting on #4802 to be merged |
There was a problem hiding this comment.
Please set $Global:PSDefaultParameterValues to the originalDefaultParameterValues.
There was a problem hiding this comment.
Why would we want to mess with global scope?
There was a problem hiding this comment.
:-) I asked @JamesWTruher previously the same and he said that is good to exclude scoped isssues.
There was a problem hiding this comment.
@JamesWTruher could you point to the PR where we had problems with scoping and PSDefaultParameterValues
There was a problem hiding this comment.
Actually, had an issue with scoping where it affected the CIM cmdlet tests on non-Windows. Changed it to global and it fixed the issue. Would like to understand what is happening here as it's not intuitive.
There was a problem hiding this comment.
Please use a more descriptive variable name.
There was a problem hiding this comment.
Set $Global:PSDefaultParameterValues instead
There was a problem hiding this comment.
This check seems unnecessary as $plugin.PSPath is already checked.
There was a problem hiding this comment.
Please move the value calculated for Should Be to a variable. It will make it more readable.
There was a problem hiding this comment.
Should this be BeExactly
There was a problem hiding this comment.
This can be Remove-Item "WSMan:\localhost\Plugin\TestPlugin2\" -Force -ErrorAction SilentlyContinue and remove the Test-Path.
There was a problem hiding this comment.
Can you use Enable-PSRemoting instead? I'd like to steer everyone in that direction now that the cmdlet is supported. An alternative is to modify the script to use the cmdlet internally. That way everyone will use it without noticing.
Thoughts?
There was a problem hiding this comment.
I don't need remoting to actual work for the purpose of these tests, I think I'll simplify it by just getting the first endpoint and validating against that
|
@SteveL-MSFT Looks like a few tests are failing |
|
@mirichmo I'm going to revert back to using microsoft.powershell plugin as my base plugin since that seems to be well defined and trying to make it work with enable-psremoting turned out to be more complicated than it's worth particularly since I'm not actually using remoting for these tests. |
b1b9b93 to
25d9d99
Compare
|
@adityapatwardhan your feedback has been addressed |
iSazonov
left a comment
There was a problem hiding this comment.
LGTM with monor comments.
There was a problem hiding this comment.
Maybe use as in line 50 > $null?
There was a problem hiding this comment.
I'll change it to $null = for consistency
There was a problem hiding this comment.
Please place a comment on new line.
There was a problem hiding this comment.
I think the request here was to move the comment on line 115 to a new line, not insert a newline character after it.
This isn't a blocking issue for the PR. I'm just clarifying intent.
|
@adityapatwardhan Can you update your review |
|
Thanks for all the updates @SteveL-MSFT. I'll merge the PR once the tests pass |
54e71f5 to
99eef43
Compare
|
Travis-CI failures due to resx tests not finding resources that don't exist there (like cimcmdlets). After discussion with @JamesWTruher we decided that it is ok to skip those tests on non-Windows. Easier to just make that change in this PR than making another PR and pulling it in. |
added tests for get-item, get-childitem, set-item, new-item remove-item, clear-item, dynamic parameters
merged CoreClr and FullClr code
did not add tests for clientcert handling
Part of #4158
Should get line coverage from 50.39% to 72.2%
Lots of error handling code not hit