- Notifications
You must be signed in to change notification settings - Fork 100
Refactor tests testmodules #297
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
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think test modules should use the namespace: Microsoft.PowerShell.Test.*
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
test/testRepositories.xml Outdated
| <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" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these file paths only work on Windows and only if that machine has C: drive which isn't guaranteed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
test/FindResource.Command.Tests.ps1 Outdated
| catch {} | ||
| | ||
| $res | Should -BeNullOrEmpty | ||
| {Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore} | Should -Throw -ExceptionType ([ArgumentException]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| {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]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is -ErrorAction Ignore used here?
| Find-PSResource -Name "test_command_module" -Version "*" -Repository $TestGalleryName | ForEach-Object { | ||
| if($_.Name -eq "test_command_module") { | ||
| $expectedModules += $_.Name | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were going to use namespaced test module names?
| $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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 test/PSGetTestUtils.psm1 Outdated
| $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"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lots of repetition, so recommend storing repeated values in a variable in case they need to change in the future or reused
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stored in variable.
test/FindResource.Command.Tests.ps1 Outdated
| $PSGalleryName = Get-PSGalleryName | ||
| $CommandTest = Get-CommandTestModule | ||
| Get-NewPSResourceRepositoryFile | ||
| Get-RegisterLocalRepos |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Get-RegisterLocalRepos | |
| Register-LocalRepos |
test/FindResource.Command.Tests.ps1 Outdated
| $res = Find-PSResource -Name Az.Compute | ||
| $res | Should -Not -BeNullOrEmpty | ||
| $res.Name | Should -Be "Az.Compute" | ||
| Get-UnregisterLocalRepos |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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