Add a BeA test function which lets you test if an object is of a specific type

[Jaykul]

Thought it would be nice if Pester had a way to assert the type of variables.

[nohwnd]

To be honest I am not very happy about the name. How about calling it Should BeOfType? In my point of view that would be easier to discover and understand. Or do you have other name suggestions?

I would also prefer if the assertion thrown an error if type is not found rather that just swallow the error and output false. Because you can't be sure whether $actual is [MyType] or not if it does not exist.

I am sure you are aware that -is checks convertibility to a type compatibility of types, not the actual type of the instance. Should we do exact type matching by Should BeOfTypeExactly?

#without exactly
#all are true
"string" -is [string]
"string" -is [System.Collections.IEnumerable]
"string" -is [object]

#with exactly
#first is true, rest is false
"string".GetType() -eq [string]
"string".GetType() -eq [System.Collections.IEnumerable]
"string".GetType() -eq [object]

Uff the syntax of Should is getting in the way again...

[desek]

I agree with @nohwnd that it should be called Should BeOfType for assertion with type convertability compatibility and Should BeOfTypeExact for exact type assetion.
OfType and the postfix Exact follows known naming convetions and eases the discovery process.

However OfType might become redundant since (I want to believe) most tests are written strict.

[nohwnd]

@desek I am not sure what you meant by your last sentence. Unless you meant that Exactly would become redundant.

[desek]

Strict naming convention for the method would result in Should BeOfTypeExact.
Example postfix of Exact.

I cast my vote on strict type assetion with Should BeOfType.
Less writing, easy to discover and checking for convertability makes little to no sense in testing.

[dlwyatt]

I think it's fine to expose both strict type checking, as well as the -is operator semantics.

[nohwnd]

@desek Checking for convertibility compatibility starts to make sense once you have interfaces in your code. Checking if your concrete implementation implements an interface is pretty useful in my point of view. Not sure how useful it will be in PowerShell, but maybe (native) interface support will come with future updates of PowerShell. Also we already use Exactly for the exact matches, like Should BeExactly.

[Jaykul]

I have no problem with renaming it to BeOfType.

However, it's not correct to say that -is casts. It will only report TRUE on:

"string" -is [string] #  YOUR CLASS
"string" -is [object] # YOUR BASE CLASSES
"string" -is [System.Collections.IEnumerable] # INTERFACES YOU IMPLEMENT

The -AS operator casts, but -IS does not.

1.0 -is [int]     # FALSE
1.0 -is [decimal] # FALSE
1 -is [double]    # FALSE
1 -is [string]    # FALSE

1.0 -as [int]     -is [int]     # TRUE
1.0 -as [decimal] -is [decimal] # TRUE
1 -as [double]    -is [double]  # TRUE
1 -as [string]    -is [string]  # TRUE

Strict mode has no bearing on this.

Frankly, in my opinion it would be a huge mistake to support testing the "Exactly" version of that assertion (i.e.: .GetType().FullName -Equals $TypeName) -- that sort of test is always testing the wrong thing, and causing incorrect design decisions.

[nohwnd]

I did not say it casts, but you are right I used the incorrect word, I meant compatibility not convertibility. fixed in the previous posts. Thanks for clearing this up.

I am not sure what you mean by your last remark... Why is it testing the wrong thing?

[Jaykul]

Because there is no possibility that it matters if an object IS OF TYPE X, or is DERIVED FROM type X

Just try and write code where that would cause a problem...

[Jaykul]

P.S. Good grief, really? Failed the build for trailing white space? 😜

[nohwnd]

@Jaykul Looks like someone did not run the whole test suite before committing. 😝

Any remarks on throwing an exception when the expected type is not found?

[dlwyatt]

RE: whitespace tests, see #272 for the discussion on that. Mainly it's there to keep people from checking code in that is harder to review due to them either adding unnecessary whitespace to lines, or fixing that later (either way, generating lots of "noise" in the diff.)

[dlwyatt]

@nohwnd : I think his code is correct. The "type not found" stuff is covered in the failure message function.

Describe 'Test' {
    It 'Fails' {
        'a string' | Should BeOfType Monkey
    }
}

<#
Describing Test
 [-] Fails 57ms
   Expected: a string to be of type [Monkey], but unable to find type [Monkey]. Make sure that the assembly that contains that type is loaded.
   at line: 3 in C:\Users\dlwya_000\OneDrive\Source\Temp\test.Tests.ps1
   3:         'a string' | Should BeOfType Monkey
#>

[nohwnd]

@dlwyatt You are right! Sorry.

[Jaykul]

How do I fix the tag test, anyway? Should I really be tagging with a version?

[dlwyatt]

Don't worry about that one. It's to keep our automated publishing process in the build server from kicking in unless we intentionally prepare everything for release (same version number in the psd1 file, changelog.md, and a tag in the git repo.) If we do that, it immediately goes up to PowerShellGet, nuget.org, and Chocolatey.

That test is skipped when testing pull requests, by running Invoke-Pester with the -ExcludeTag VersionChecks parameter. The version checks only matter when it all other tests have already passed on the master branch.