-
Notifications
You must be signed in to change notification settings - Fork 7.2k
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
Added tests for builtin type accelerators #4230
Added tests for builtin type accelerators #4230
Conversation
|
||
$TypeAccelerators = $TypeAcceleratorsType::Get | ||
$TypeAcceleratorsType::Add('msft_2174855', [int]) | ||
$TypeAcceleratorsType::Add('msft_2174855_rm', [int]) |
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.
it would good to decode 'msft_2174855' and 'msft_2174855_rm' - can we use more informative names and comments for it?
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.
#Closed.
} else | ||
{ | ||
$count = 82 | ||
} |
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 believe it is better use the pattern and formatting https://github.com/PowerShell/PowerShell/blob/master/test/powershell/engine/DefaultCommands.Tests.ps1
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.
Please address the comment.
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.
Resolved in latest commit
|
||
It 'Should have a type acclerator for: <Accelerator>' -TestCases $TypeAcceleratorTestCases { | ||
param($Accelerator, $Type) | ||
$TypeAcceleratorsType::Get[$Accelerator] | Should be ($Type) |
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.
Can we use Should BeOfType
?
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 did not work as expected. The object returned by the type accelerator get is System.RuntimeType.
$TypeAcceleratorsType = [psobject].Assembly.GetType("System.Management.Automation.TypeAccelerators")
$TypeAcceleratorsType::Get['String']
$TypeAcceleratorsType::Get['String'] | Get-Member
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.
#Closed
} | ||
|
||
It "Can query type accelerators" { | ||
if ( $IsCoreCLR ) { $count = 80 } else { $count = 82 } | ||
$TypeAccelerators.Count -gt $count | Should Be $true | ||
$TypeAccelerators.Count -gt $totalAccelerators | Should Be $true |
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 it would be good to test against the exact number of built-in accelerators (89). And it's recommended to write as $TypeAccelerators.Count | Should Be $totalAccelerators
because it would give more information compared to Should Be $true
in case the test fails.
} | ||
else | ||
{ | ||
$totalAccelerators = 82 |
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 it's better to test the exact number of built-in accelerators.
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.
Understood, will make the update tonight.
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.
Thanks for adding tests for accelerators. Some comments below.
} | ||
|
||
It "Can query type accelerators" { | ||
if ( $IsCoreCLR ) { $count = 80 } else { $count = 82 } | ||
$TypeAccelerators.Count -gt $count | Should Be $true | ||
$TypeAccelerators.Count -gt $totalAccelerators | Should Be $true | ||
$TypeAccelerators['xml'] | Should Be ([System.Xml.XmlDocument]) | ||
$TypeAccelerators['AllowNull'] | Should Be ([System.Management.Automation.AllowNullAttribute]) |
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 two tests can be removed now as we are testing the complete set of accelerators 😄
} | ||
|
||
It "Can query type accelerators" { | ||
if ( $IsCoreCLR ) { $count = 80 } else { $count = 82 } | ||
$TypeAccelerators.Count -gt $count | Should Be $true | ||
$TypeAccelerators.Count -gt $totalAccelerators | Should Be $true | ||
$TypeAccelerators['xml'] | Should Be ([System.Xml.XmlDocument]) | ||
$TypeAccelerators['AllowNull'] | Should Be ([System.Management.Automation.AllowNullAttribute]) | ||
} | ||
|
||
It "Can remove type accelerator" { |
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 recommend to group this test and It "Basic type accelerator usage"
together in a Context
, and then move the initialization of userDefinedAcceleratorType
and userDefinedAcceleratorTypeToRemove
to the BeforeAll
of the Context
. And remember to clean them up in AfterAll
block of the same Context
.
Changes made, let me know how it looks. |
|
||
It 'Should have all the type accelerators' { | ||
$TypeAccelerators.Count | Should be $totalAccelerators | ||
} |
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.
Let's clarify. I still believe that we should follow the pattern to make the tests deterministic and well formatting.
It makes no sense to check the number of because that one accelerator can be replaced with other and we won't see the difference.
Accelerator may not be supported on all protforms. So we should check this by " $($FullCLR -or $CoreWindows -or $CoreUnix)".
Formatting should be tabular. It is more compact and we can read easy:
$TypeAcceleratorTestCases = @"
"Accelerator", "Type", "Present"
"wmisearcher", "System.Management.ManagementObjectSearcher", $($FullCLR -or $CoreWindows -or $CoreUnix)
"@
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.
It makes no sense to check the number of because that one accelerator can be replaced with other and we won't see the difference.
There are tests to check each of the accelerators, so we will see a failure if one is replaced with another. This "count" test makes sure no new accelerator is added accidentally.
Accelerator may not be supported on all protforms. So we should check this by " $($FullCLR -or $CoreWindows -or $CoreUnix)".
Accelerators are essentially .NET types, so I think there is no difference between CoreWindows
and CoreUnix
as they both use .NET Core.
I still believe that we should follow the pattern to make the tests deterministic and well formatting.
I agree that the DefaultCommands.Tests.ps1
is well-formatted and I recommend to use a similar pattern. But I don't think a PR should be blocked if it's clear enough (not confusing in any ways).
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.
Thanks for clarify!
There are tests to check each of the accelerators, so we will see a failure if one is replaced with another. This "count" test makes sure no new accelerator is added accidentally.
If we have explicit full accelerator list in the file we catch the problem - in DefaultCommands.Tests.ps1 we compare two arrays for this.
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.
Yes, I see your point. In DefaultCommands.Tests.ps1
we guarantee no unexpected alias
or cmdlet
by comparing the full list and that's why we don't need the count check in that test.
{ | ||
$totalAccelerators = 89 | ||
} else | ||
{ |
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.
Should be
}
else
{
It "Basic type accelerator usage" { | ||
[msft_2174855] | Should Be ([int]) | ||
} | ||
$nonCoreTypeAcceleratorTestCases = @( |
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.
Can you please change the name to $extraFullPSAcceleratorTestCases
?
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.
LGTM
First pass of tests for built in type accelerators.
Referenced in issue: #4221