Skip to content

Conversation

@anamnavi
Copy link
Member

@anamnavi anamnavi commented Oct 26, 2020

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

@anamnavi anamnavi self-assigned this Oct 28, 2020
$res = Find-PSResource -Name NonExistantCommand
$res | Should -BeNullOrEmpty
It "find Command resource given Name parameter" {
$res = Find-PSResource -Name "test_command_module"
Copy link
Member

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.*

Copy link
Member Author

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.

<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" />
Copy link
Member

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

Copy link
Member Author

@anamnavi anamnavi Nov 17, 2020

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.

catch {}

$res | Should -BeNullOrEmpty
{Find-PSResource -Name "test_command_module" -Version $Version -Repository $TestGalleryName -ErrorAction Ignore} | Should -Throw -ExceptionType ([ArgumentException])
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
{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])
Copy link
Member

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
}
Copy link
Member

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
Copy link
Member

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 {
Copy link
Member

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
$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"},
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

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

stored in variable.

$PSGalleryName = Get-PSGalleryName
$CommandTest = Get-CommandTestModule
Get-NewPSResourceRepositoryFile
Get-RegisterLocalRepos
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Get-RegisterLocalRepos
Register-LocalRepos
$res = Find-PSResource -Name Az.Compute
$res | Should -Not -BeNullOrEmpty
$res.Name | Should -Be "Az.Compute"
Get-UnregisterLocalRepos
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Get-UnregisterLocalRepos
Unregister-LocalRepos

Register and Unregister are approved verbs

@anamnavi anamnavi closed this Jun 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants