@iSazonov PR is ready to merge, CodeFactor issues are not new.

Pass 'BeOfType' parameter as [RuntimeType] instead of [string]

I don't think changes related to this one are needed. -BeOfType takes a string as the type name, and this is how it's used in Pester's sample code.

@daxian-dbw Judging from BeOfType tests, it is intended for -BeOfType to take a RuntimeType as well as a string. Apparently this is a documentation issue for pester.

Passing a RuntimeType might be preferable because:

• it could be recognised as a type in the AST
• the type object is constructed in the same scope as the assertion, e.g.:

using namespace System.Management.Automation
Describe "scope test"  {
    $p = [ActionPreference]::Continue
    it "should recognise type passed explicitly" {
        $p | Should -BeOfType ([ActionPreference]) # Passes
    }
    it "should recognise type passed as string" {
        $p | Should -BeOfType ActionPreference     # Fails
    }
}

Usually we use $p | Should -BeOfType [ActionPreference]

@iSazonov The parentheses are necessary for the parser to treat the token [ActionPreference] as an expression. Otherwise it is parsed as a string anyway:

$p | Should -BeOfType [ActionPreference]   # Fails

@xtqqczze I won't say either a RuntimeType or a string is preferable. Both are officially supported and both are useful. If you don't expect the type resolution to depend on anything from your script scope, then using a string is just fine. So I don't think it's necessary to change all -BeOfType instances to use a RuntimeType. We will not enforce this in our tests and gradually, it will again be a mix of both in our tests.

rebased to resolve merge confilcts

🎉v7.1.0-preview.1 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes