AboutPSProviders.Koans.ps1 - thows errors (may be unavoidable)

[DEberhardt]

Describe "Koan Bug, Issue, or Help Request"

AboutPSProviders.Koans.ps1

Context "The Problematic Assertions"

Invoke-Koan : This command cannot find a matching alias because an alias with the definition '____' does not exist.
At C:\Users\David\Documents\WindowsPowerShell\Modules\PSKoans\0.67.1\Public\Get-Karma.ps1:111 char:32
+                 $PesterTests = Invoke-Koan @{
+                                ~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (____:String) [Invoke-Koan], ItemNotFoundException
    + FullyQualifiedErrorId : ItemNotFoundException,Invoke-Koan

Invoke-Koan : Cannot find drive. A drive with the name 'TEMP' does not exist.
At C:\Users\David\Documents\WindowsPowerShell\Modules\PSKoans\0.67.1\Public\Get-Karma.ps1:111 char:32
+                 $PesterTests = Invoke-Koan @{
+                                ~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (TEMP:String) [Invoke-Koan], DriveNotFoundException
    + FullyQualifiedErrorId : DriveNotFound,Invoke-Koan


    Welcome, seeker of enlightenment.
    Let us observe your karma...

Describing "Alias Provider" has damaged your karma.

Context "Your Attempts"

None to resolve directly. Don't know enough about this to dig though this yet 😄

Context "Additional Information"

The relevant function in Get-Karma

# Execute in a fresh scope to prevent internal secrets being leaked
$PesterTests = Invoke-Koan @{
    Script   = $KoanFile.Path
    PassThru = $true
    Show     = 'None'
}

[vexx32]

Ah, yep, looks like we need to be making sure we load the Get-Blank function and its aliases into the new runspace, which it seems we're not doing at the moment. Definitely seems like something we need to look into here.

[DEberhardt]

in the same Kaon, the following I cannot overcome:

Cannot process argument transformation on parameter 'ExceptionType'. Cannot
convert the "ItemNotFoundException" value of type "System.String" to type
"System.Type".

    Please meditate on the following code:

× It "allows you to copy, rename, or delete files"
at <ScriptBlock>, C:\Users\David\PSKoans\Cmdlets 1\AboutPSProviders.Koans.ps1:
line 174
174:         { Get-Item -Path $FilePath -ErrorAction Stop } | Should -Throw
-ExceptionType 'ItemNotFoundException'

Line 174 reads:
{ Get-Item -Path $FilePath -ErrorAction Stop } | Should -Throw -ExceptionType 'ItemNotFoundException'

ItemNotFoundException is what my error returns:

❯ $Error[1].CategoryInfo


Category   : ObjectNotFound
Activity   : Get-Item
Reason     : ItemNotFoundException
TargetName : C:\Users\David\AppData\Local\Temp\TESTNAME.tmp
TargetType : String

so don't know what is actually wrong here...

[vexx32]

When handling types, you will often need to qualify them by a namespace name if they're not in the default set of namespaces. If you grab $error[1].Exception.GetType().Fullname you'll see the full type name you can use for that assertion. 🙂

[DEberhardt]

The main error here leads to:

Expected 123, but got $null

The respective Test is the following:

        It 'allows you to remove variables' {
            $Test = 123

            123 | Should -Be $Test

            Remove-Item -Path 'Variable:\Test'
            $null | Should -Be $Test
            { Get-Item -Path 'Variable:\Test' -ErrorAction Stop } | Should -Throw -ExceptionType PathNotFound
        }

I tried to overcome this with changing line 261 to:
Remove-Item -Path 'Variable:\Test' -Force
but this did not work

Commenting out Line 261 will lead to another error on the next line.
Don't know if I am doing something wrong here, but this is what I get:

Cannot process argument transformation on parameter 'ExceptionType'. Cannot
convert the "PathNotFound" value of type "System.String" to type "System.Type".

(same as above)

[DEberhardt]

further on, I get a similar thing:

        It 'allows you to set variable options' {
            Set-Variable -Name 'Test' -Value 'TEST'

            $Var = Get-Item -Path 'Variable:\Test'
            $Var.Options = [System.Management.Automation.ScopedItemOptions]::ReadOnly

            'TEST' | Should -Be $Var
            { Remove-Item -Path 'Variable:\Test' -ErrorAction Stop } | Should -Throw -ExceptionType PathNotFound
        }

which gives me:

Expected System.Management.Automation.PSVariable, but got 'TEST'.

    Please meditate on the following code:

× It "allows you to set variable options"
at <ScriptBlock>, C:\Users\David\PSKoans\Cmdlets 1\AboutPSProviders.Koans.ps1:
line 280
280:             'TEST' | Should -Be $Var

the premise is to insert a string '____' which I presume to be the value of the variable
should this be 'TEST' | Should -Be $Var.Value? (which works)

Line 281 again fails because the variable cannot be removed

[DEberhardt]

When handling types, you will often need to qualify them by a namespace name if they're not in the default set of namespaces. If you grab $error[1].Exception.GetType().Fullname you'll see the full type name you can use for that assertion. 🙂

Thank you. Didn't know you can drill down that far into Error-messages... I am usually content handling the $_.Exception.Message in catch blocks :)

[FH-Inway]

Regarding #455 (comment), I got the same issue with variable $Test with value 123 that should be $null after the variable was removed.
It works when I do it in the console.
When I tried to do Remove-Item -Path 'Variable:\*' -Force, I got a bunch of error messages, one of them saying

Cannot remove variable Test because the variable has been optimized and is not removable. Try using the Remove-Variable cmdlet (without any aliases), or dot-sourcing the command that you are using to remove the variable.

I added the Remove-Variable call, which resolved the issue, but is probably not the intended result of the Koan.

Seems related to #435

[FH-Inway]

Regarding #455 (comment), I'm also confused why It 'allows you to set variable options' requires System.Management.Automation.PSVariable instead of 'TEST' as the solution for the '____' | Should -Be $Var check.