Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Refactor tests testmodules #297
Conversation
| $res = Find-PSResource -Name NonExistantCommand | ||
| $res | Should -BeNullOrEmpty | ||
| It "find Command resource given Name parameter" { | ||
| $res = Find-PSResource -Name "test_command_module" |
SteveL-MSFT
Nov 2, 2020
Member
I think test modules should use the namespace: Microsoft.PowerShell.Test.*
anamnavi
Nov 17, 2020
Author
Collaborator
I discussed this with Amber and her view was that we may be better off changing this when we move to NuGet gallery or reach the situation when we need the names to have the Microsoft namespace to stand out and not conflict with generic test modules. The way to change the name from something like test_module to Microsoft.PowerShell.Test.* is to either create a new module with this name or to update it in the database/from the backend which Amber could do. It's not a simple update by publishing the module with an updated version (with the name change made in). So her suggestion was to update once when we know for sure what we want it to be like.
| @@ -1,6 +1,8 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <configuration> | |||
| <Repository Name="psgettestlocal" Url="file:///c:/code/testdir" Priority="50" Trusted="false" /> | |||
|
|
|||
| <Repository Name="psgettestlocal" Url="file:///c:/code/testdir" Priority="40" Trusted="false" /> | |||
SteveL-MSFT
Nov 2, 2020
Member
these file paths only work on Windows and only if that machine has C: drive which isn't guaranteed
anamnavi
Nov 17, 2020
•
Author
Collaborator
Good point! My thought was that this filepath gets changed before it's ever used, but I see that it's better to not have to rely on that alone. Better to not introduce something that could cause an issue later or if misused. Additionally, this really helped my understanding of how PSGet registers the default repos and which ones. I removed this and instead register the test repo and unregister it in the PSGetTestUtils file now, with Join-Path to create the path.
… into refactor-tests-testmodules
…ng load on PSGallery
… into refactor-tests-testmodules
| catch {} | ||
|
|
||
| $res | Should -BeNullOrEmpty | ||
| {Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore} | Should -Throw -ExceptionType ([ArgumentException]) |
SteveL-MSFT
Nov 17, 2020
Member
| {Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore} | Should -Throw -ExceptionType ([ArgumentException]) | |
| { Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore } | Should -Throw -ExceptionType ([ArgumentException]) |
| Find-PSResource -Name "test_command_module" -Version "*" -Repository $TestGalleryName | ForEach-Object { | ||
| if($_.Name -eq "test_command_module") { | ||
| $expectedModules += $_.Name | ||
| } |
SteveL-MSFT
Nov 17, 2020
Member
Is there a reason to filter out incorrect results that may be returned? Seems like this test should validate that each returned module has the right name
| ) { | ||
| param($Version, $Description) | ||
|
|
||
| $res = Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore |
| $res = Find-PSResource -ModuleName "test_module" -Version "*" -Repository $TestGalleryName | ||
| $res.Count | Should -Be 7 | ||
| $expectedModules = @() | ||
| Find-PSResource -ModuleName "test_module" -Version "*" -Repository $TestGalleryName | ForEach-Object { |
SteveL-MSFT
Nov 17, 2020
Member
This code is similar in several cases, you can use -TestCases with splatting to cover different parameter variations and use the same validation code. Something like:
It "... with parameter '<Parameter>'" -TestCases @(
@{ Parameter = 'Name' }
@{ Parameter = 'ModuleName' }
) {
param($parameter)
...
$parameters = @{
$parameter = 'test_module'
Version = '*'
Repository = $TestGalleryName
}
Find-PSResource @parameters| @@ -30,6 +30,50 @@ $script:PSGalleryLocation = 'https://www.powershellgallery.com/api/v2' | |||
| $script:PoshTestGalleryName = 'PoshTestGallery' | |||
| $script:PostTestGalleryLocation = 'https://www.poshtestgallery.com/api/v2' | |||
|
|
|||
| $script:command_test_module = @( | |||
| @{Name="test_command_module"; Version="2.5.0.0"; Repository="PoshTestGallery"; Description="this a test command resource of type module"}, | |||
SteveL-MSFT
Nov 17, 2020
Member
lots of repetition, so recommend storing repeated values in a variable in case they need to change in the future or reused
| $res = Find-PSResource -Name Az.Compute | ||
| $res | Should -Not -BeNullOrEmpty | ||
| $res.Name | Should -Be "Az.Compute" | ||
| Get-UnregisterLocalRepos |
JamesWTruher
Nov 17, 2020
Member
| Get-UnregisterLocalRepos | |
| Unregister-LocalRepos |
Register and Unregister are approved verbs
Refactored the Find tests to use test modules instead of production modules. Since the team has control and ownership over these test modules, testing for an exact version or anything else that is dependent upon the package not being updated is less error prone than before. This makes the tests more reliable as a failing test would indicate an error with the code, not dependent packages having changed. Resolves #263