Is there any reason why class defined in a module can't be subsclassed in Pester testcase?

[plastikfan]

I recently discovered that attempting to subclass a class defined in the module under test results in an error, even though the class type is available. Consider this:

SourceControl is a class defined in the module being tested

class SourceControl {
  hidden [PSCustomObject[]]$_allTags;
  hidden [DateTime]$_headDate;
...
}

In a Pester test case, with test code running InModuleScope

  BeforeAll {
    Get-Module Elizium.Loopz | Remove-Module
    Import-Module .\Output\Elizium.Loopz\Elizium.Loopz.psm1 `
      -ErrorAction 'stop' -DisableNameChecking;

    InModuleScope -ModuleName Elizium.Loopz {
      # This class reference is ok:
      #
      [SourceControl]::New();

      # Attempting to inherit from a class is not ok
      #
      class TestGit : SourceControl {

      }
    }
  }

results in error:

System.Management.Automation.ParseException: At C:\Users\Plastikfan\dev\github\PoSh\Loopz\Elizium.Loopz\Tests\Classes\change-log.tests.ps1:24 char:23
+       class TestGit : SourceControl {
+                       ~~~~~~~~~~~~~
Unable to find type [SourceControl].
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at Invoke-File(Closure , FunctionContext )
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.CommandProcessorBase.Complete()

Currently, the only way around this is to define TestGit inside the module and reference the class from the test. However, this is sub-optimal because the module now contains test code.

So what is the limitation here? Is this a PowerShell problem or a Pester problem, or am I doing something wrong?

We clearly can't fix this via a using module statement at the top of the test file, because the module is the one being tested and is imported inside BeforeAll, which doesnt include class definitions, but the class is 'semi-visible'; we can new it, but not inherit from it. I'm just wondering what's the difference between these?

[fflaten]

This is a PowerShell-issue. Repro:

Get-Module demoModule | Remove-Module
$m = New-Module -Name demoModule -ScriptBlock {
    class BaseDemo {
        [string] echo ($message) {
            return $message
        }
    }
} | Import-Module -PassThru

& ($m) {
    # This class reference is ok:
    #
    $d = [BaseDemo]::New();
    Write-Host $d.echo("hello world!")

    # Attempting to inherit from a class is not ok
    #
    class TestGit : BaseDemo {
        [string] SomeEcho ($message) {
            return "hello {0}" -f $message
        }
    }

    $d = [TestGit]::new()
    Write-Host $d.SomeEcho("fflaten")
}

# Output
At line:9 char:21
+     class TestGit : BaseDemo {
+                     ~~~~~~~~
Unable to find type [BaseDemo].
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : TypeNotFound

It looks like the "class new : base" expression might be evaluated before the scriptblock is executed in the module session state where the base is available. If we create it as a string, it's delayed enough to work. Ex:

Get-Module demoModule | Remove-Module
$m = New-Module -Name demoModule -ScriptBlock {
    class BaseDemo {
        [string] echo ($message) {
            return $message
        }
    }
} | Import-Module -PassThru

& ($m) {
    # This class reference is ok:
    #
    $d = [BaseDemo]::New();
    Write-Host $d.echo("hello world!")

    # Inherit from a module-defined class is ok
    #
    . ([ScriptBlock]::Create('
    class TestGit : BaseDemo {
        [string] SomeEcho ($message) {
            return "hello {0}" -f $message
        }
    }'))

    $d = [TestGit]::new()
    Write-Host $d.SomeEcho("fflaten")
}

# Output 
hello world!
hello fflaten

[nohwnd]

Yes I can confirm classes are parsed out from the code and evaluated before it. But that is about as much as I know about them.

[fflaten]

👍 Someone should probably create a issue in the powershell-repo to get this explained and documented (or fixed if not intended) as it goes against normal behavior in powershell. Are there any other situations where parts of a scriptblock is evaluated prior to the rest? 😕

[plastikfan]

@fflaten, thanks for your response. You have confirmed what I feared and I'll just have to accept including a test class in my module. I tried you solution and although referencing the class from inside of the same BeforeAll block does actually work:

  BeforeAll {
    Get-Module Elizium.Loopz | Remove-Module
    Import-Module .\Output\Elizium.Loopz\Elizium.Loopz.psm1 `
      -ErrorAction 'stop' -DisableNameChecking;

    InModuleScope -ModuleName Elizium.Loopz {

      . ([ScriptBlock]::Create('
    class TestGit : SourceControl {
        [string] SomeEcho ($message) {
            return "hello {0}" -f $message
        }
    }'));

      [TestGit]::new(); # => this class reference works ok
    }
  }

... accessing from inside a test, still doesnt work:

  It 'should: be able to reference class definition' {
    InModuleScope Elizium.Loopz {
       # Fails: RuntimeException: Unable to find type [TestGit]
       [TestGit]::new();
    }
  }

This is a bit of a moot point, because even if it did work, writing test code inside a non parsable string looks very precarious and probably inferior to just including the test code in the module.

I'm just willing to accept this as one of the many things that are wrong/deficient with the current design of classes in PowerShell.

[fflaten]

That's a scoping-issue. A variable or function would also be lost between different calls to InModuleScope or & (Get-Module demoModule) { ... } to keep it plain powershell - unless you define them using the global: or script: scope-identifier. AFAIK you can't specify that for classes directly, so yet another feature request for the powershell-repo.

You could however workaround this by storing the new type-reference in a variable in the right scope.
Ugly: Yes
Does it work: Yes

Describe "Class inheritance in module demo - Workaround" {
    BeforeAll {
        Get-Module demoModule | Remove-Module
        $m = New-Module -Name demoModule -ScriptBlock {
            class SourceControl { }
        } | Import-Module -PassThru

        InModuleScope -ModuleName demoModule {
            . ([ScriptBlock]::Create('
                class TestGit : SourceControl {
                    [string] SomeEcho ($message) {
                        return "hello {0}" -f $message
                    }
                }'));

            $script:myClass = [TestGit]
            Write-Host ($myClass::new().SomeEcho("from BeforeAll")) -ForegroundColor Yellow
        }
    }

    It "Success" {
        InModuleScope -ModuleName demoModule {
            $myClass::new().SomeEcho("from It")
        } | Should -BeExactly "hello from It"
    }
}

[fflaten]

@plastikfan Actually we can workaround this even better by adding the using module statement to expose the SourceControl-class in the script state where class TestGit : SourceControl is evaluated (for some unexpected reason). That way you don't need the ugly string-scriptblock.

demoModule.psm1

class SourceControl {
    [string] Echo ($message) {
        return "SourceControl says: {0}" -f $message
    }
}

demoModule.tests.ps1

using module ".\demoModule.psm1"

Describe "Class inheritance in module demo - Workaround" {
    BeforeAll {
        Get-Module demoModule | Remove-Module
        Import-Module ".\demoModule.psm1"

        InModuleScope -ModuleName demoModule {
            class TestGit : SourceControl {
                [string] Echo ($message) {
                    return "TestGit says: {0}" -f $message
                }
            }

            # Store runtime-defined class for future use
            $script:myClass = [TestGit]

            Write-Host ([SourceControl]::new().Echo("Hello from BeforeAll")) -ForegroundColor Yellow
            Write-Host ([TestGit]::new().Echo("Hello from BeforeAll")) -ForegroundColor Green
        }
    }

    It "Success" {
        InModuleScope -ModuleName demoModule {
            Write-Host ([SourceControl]::new().Echo("Hello from It")) -ForegroundColor Yellow
            Write-Host ($myClass::new().Echo("Hello from It")) -ForegroundColor Green
        }
    }

    AfterAll { Get-Module demoModule | Remove-Module }
}

[plastikfan]

Nice! Actually, I didnt know you could use ''using module' directly on a .psm1 file. Thats a game changer for me! I've only ever applied it to a literally specified module name.

[plastikfan]

PS, I changed the answer to this item, but now it looks like I answered the question when the kudos should be going to @fflaten. (Possibly a change request to github, do get that tick answer button placement changed)

[fflaten]

Nothing wrong with Github. The "problem" is that you created an answer to respond to my first post instead of replying to it as a comment. And since you introduced a follow-up issue, I continued in that answer-thread. I'd have to move the comment into a new answer to fix who gets the kudos, but I don't really worry about it - as long you got the answered needed. 👍

As for using module, it allows path relative to the scripts location or absolute path.