-
-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose pester state inside suite #318
Comments
Thanks, interesting idea. Could you share more details about the use case, please? |
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."
}
} |
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 |
Nope, I cannot do that:
I need to make |
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. |
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. |
@nohwnd 🙏 great |
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
The text was updated successfully, but these errors were encountered: