Fix GetType() bad pattern and related issues in tests#3134
Conversation
There was a problem hiding this comment.
pipe will unwrap the input collection, so this will become checking the type of individual elements instead of the collection as a whole. Better keep what it was in this case.
There was a problem hiding this comment.
can this be $_.Exception | Should BeOfType $exception?
There was a problem hiding this comment.
I see what is happening. $exception is point to internal types, and thus Pester cannot resolve. #Closed
There was a problem hiding this comment.
`$result.GetType().BaseType | Should Be 'System.Object' seems not interesting, maybe remove it?
There was a problem hiding this comment.
Is it failing? If it is we better have an issue tracking it.
There was a problem hiding this comment.
OsLocalDateTime return empty to me. And the test is wrong. Yes, we should open a new Issue...
There was a problem hiding this comment.
Yup, the test doesn't do anything about OsLocalDateTime. Please open an issue.
There was a problem hiding this comment.
I believe that the test is similar to the following after it. So it is better to leave.
There was a problem hiding this comment.
if any of those aliases are removed, these tests can catch it. So maybe we should keep these 3 tests?
There was a problem hiding this comment.
We have separate files with tests for aliases. If we need control a list of approved aliases we should make the test there. If it is we should open a new Issue.
There was a problem hiding this comment.
Yes, please open an issue to verify the approved aliases exist in powershell. The test can be added to Microsoft.PowerShell.Utility\Default-Aliases.Tests.ps1.
There was a problem hiding this comment.
indentation. there are similar indentation problems down in the changes.
There was a problem hiding this comment.
I reformat the file.
There was a problem hiding this comment.
Is it failing on Linux? I don't see this failure in our daily build ... Can you open an issue for it?
There was a problem hiding this comment.
I only add the comment for you. I don't mark it as pending.
The code don't raise an exception as expected in the test (on windows). So we should open a new Issue.
There was a problem hiding this comment.
Weird, it pass in daily build, but no exception is thrown when I run it locally.
@PaulHigin can you please take a look?
There was a problem hiding this comment.
?? This test runs fine on Linux for me. The CI test failures only indicate that the class inheritance tests fail. Why do you think this test is failing?
There was a problem hiding this comment.
I copy-paste the code
[System.Management.Automation.Runspaces.SSHConnectionInfo]::new(
[System.Management.Automation.Internal.AutomationNull]::Value,
"localhost",
[System.Management.Automation.Internal.AutomationNull]::Value)to interactive session (on Windows) and it don't raise exception.
There was a problem hiding this comment.
Oh I see now. Yes, this test should be removed because the code now gets the current user name if no user name is specified. Good find.
There was a problem hiding this comment.
Clear. Thanks! I'll remove the test.
There was a problem hiding this comment.
@PaulHigin Why doesn't it fail in our daily test run then? There is no current user name when running daily test pass in AppVeyor builder?
There was a problem hiding this comment.
Not sure. But the test is incorrect (no longer needed) because a null UserName parameter is now allowed, and the test should be removed.
There was a problem hiding this comment.
The test is removed.
There was a problem hiding this comment.
You use $result | Should BeOfType in some places, and $result | Should Not BeNullOrEmpty then $result.Exception.GetType | Should Be in some other places. Why don't you unify them with a single pattern?
There was a problem hiding this comment.
Sometimes it is clear from above code that '$result' is not empty. Ex. $result.Count | Should Be 2
There was a problem hiding this comment.
I see, if it's obvious $result is not null, you will go with $result | should BeOfType. If not, you will check $result | Should Not BeNullOrEmpty first.
But after checking "Not BeNullOrEmpty", why not also use $result | should BeOfType? I see in some places you just continue to use $result.GetType() | Should Be.
There was a problem hiding this comment.
$ev will always be an arraylist, but it might be empty. I think here you want to test $ev[0] | Should Not BeNullOrEmpty.
There was a problem hiding this comment.
We should not trust a cmdlet which we check.
If $ev != Null then $ev[0] never raise.
So I suppose $ev | Should Not BeNullOrEmpty is correct.
There was a problem hiding this comment.
this extra test doesn't really get you that much. If $HtAst is null, or if GetType is null, or $HtAst.SafeGetValue() doesn't return a hashtable, the test will fail regardless.
Doesn't just $HtAst.SafeGetValue() | should beoftype hashtable suffice?
most of the validating that the return value isn't null doesn't provide that much value (as the test will fail when the method is called), and in the case that it is not a failure, only adds time to the test.
There was a problem hiding this comment.
I removed "GetType().Name" However, previously we need to check that $HtAst is not Null to exclude exception.
$var.GetType() can raise an exception in tests so we should check $var before make the call. A large part of the tests does not make this check. I start with searching ".GetType()" but discovered many related issues in tests (reduntant and unneeded tests, "throw" bad pattens, bugs, formattings (sorry!) and so on) - I had to fix them too.
2ca9f96 to
c442923
Compare
Removed 'GetType().Name' patterns.
c442923 to
28eee62
Compare
|
Sorry I accidentally made a rebase 😕 |
|
@daxian-dbw Thanks for the very fast code review! 👍 |
$var.GetType() can raise an exception in tests so we should check $var
before make the call. A large part of the tests does not make this
check.
I start with searching ".GetType()" but discovered many related issues
in tests (reduntant and unneeded tests, "throw" bad pattens, bugs,
formattings (sorry!) and so on) - I had to fix them too.
According to our test roadmap, we must increase the code coverage from 45 up to 90% i.e. twice. Bad patterns and bad formatting will slow down our movement. I hope the team will support me in this PR.