Expose pester state inside suite

[vors]

Scenario: I have a clean-up logic in my test suite. I don't want to run it, if one of the tests failed or throw. I want to preserve everything as is for future investigations.

How I can achieve it?
I can pull cleanup logic to a separate file that calls Invoke-Pester -PassThru and exam result object. But my cleanup exists in the form of test (I tests cleanup logic itself in the cleanup). I would like to have an ability to get some knowledge about fails directly in tests, so I can make a decision, run cleanup tests or not in the same suite.

Suggested solution: provide API (function) to get an immutable copy of current PesterState

[nohwnd]

Thanks, interesting idea. Could you share more details about the use case, please?

[vors]

Sure, here is a pseudo test:

Describe 'workflow with azure VMs' {

  It 'creates a VM succesfully' {
    $VM = New-VM
    $VM | Should Not Be $null
  }

  It 'execute foo on the VM' {
    Invoke-Foo $VM
    Get-FooStatus $VM | Should be OK
  }

  if ($PesterState -eq 'Good') {
    It 'remove VM' {
        Remove-VM $VM | Should be OK
    }
  } else {
    Write-Warning "VM $VM is left for investigations, please remove it manually."
  }

}

[vors]

But, I actually found a work-around:

Describe 'foo' {
    $failed = $true
    It 'fails intentionally' {
        1 | Should Be 2
        $failed = $false
    }

    It 'didn''t execute It after failed Should' {
        $failed | Should be $true
    }
}

So I can achieve my goal with this obscure method:

Describe 'workflow with azure VMs' {

  $failed = $true

  It 'creates a VM succesfully' {
    $VM = New-VM
    $VM | Should Not Be $null
  }

  It 'execute foo on the VM' {
    Invoke-Foo $VM
    Get-FooStatus $VM | Should be OK
    $failed = $false
  }

  if (-not $failed) {
    It 'remove VM' {
        Remove-VM $VM | Should be OK
    }
  } else {
    Write-Warning "VM $VM is left for investigations, please remove it manually."
  }

}

When I start adding more It statements my logic around $failed become even less clear.
So it would be nice to have some knowledge about state anyway.

[vors]

Nope, I cannot do that:

Describing workflow with azure VMs
 [+] creates a VM succesfully 37ms
 [+] execute foo on the VM 8ms
WARNING: VM  is left for investigations, please remove it manually.

I need to make $failed $script:failed to achieve the result.
#336 for that.

[TravisEz13]

It would be nice if the test could take different action in the after* based on the state. One example could be to collect detailed logs you don't want to consume space for on a run where it is not applicable. Cleanup is another example.

[nohwnd]

This is generally possible in the new runtime, and there are first steps towards this. The internal structure is built around this.

It will be no problem to expose the current test / current block or even the whole internal state to the test / block. I just don't want to do it in v5, I want to allow some time for the internals to dogfood this, and for the structure to stabilize.

[vors]

@nohwnd 🙏 great