profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/bozho/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

bozho/console 114

Public Console repo

akirill/console 13

If you clone work/* branches, be prepared for them to be rebased.

bozho/AnsiColorOut 11

ANSI color output for PowerShell

bozho/Flexget 1

The official FlexGet repository. Issue Tracker: http://flexget.com/report Forum: http://discuss.flexget.com

bozho/cChoco 0

Community resource to manage Chocolatey

bozho/SylphyHorn 0

Virtual Desktop Tools for Windows 10.

bozho/VirtualDesktop 0

Wrapper for API to Virtual Desktop on Windows 10.

bozho/Windows-universal-samples 0

API samples for the Universal Windows Platform.

issue closedpester/Pester

v5: BeforeAll and BeforeEach in different scopes execution order

<!-- Thank you for using Pester and taking the time to report this issue! Only Pester 4.10.x and 5.x.x are supported, try updating to the latest version to see if that solves your problem. See Installation and update guide.

  • Please update Pester and retest your code before submitting a bug report. See Installation and update guide.
  • Search for existing issues.
  • Pester 5 introduced breaking changes and some features were removed or are not yet migrated. See Breaking changes -->

General summary of the issue

I don't know if this is working as intended, or a bug. I have a test that would look like this:

Describe 'Description' {
    BeforeEach {
        # Do some expensive setup before each Context
        Write-Host 'BeforeEach'
    }

    Context 'Context 1' {
        BeforeAll {
            # Modify stuff loaded in BeforeEach above
            Write-Host 'BeforeAll 1'
        }

        It 'It 1.1' {
            ...
        }

        It 'It 1.2' {
            ...
        }
    }

    Context 'Context 2' {
        BeforeAll {
            # Modify stuff loaded in BeforeEach above
            Write-Host 'BeforeAll 2'
        }

        It 'It 2.1' {
            ...
        }

        It 'It 2.2' {
            ...
        }
    }
}

When I run the test, I get this:

BeforeAll 1
BeforeEach
BeforeEach
BeforeAll 2
BeforeEach
BeforeEach

If I change BeforeAlls to BeforeEach's, I get the expected order of execution, but I'd like to avoid running each Context's Before... block before each It inside the Context.

My expectation here would be that BeforeEach above runs before anything in each Context, and then each BeforeAll runs before all Its in a given Context.

Describe your environment

<!-- Please provide the output of this script: (Invoke-WebRequest -Uri "https://git.io/JTinj" -UseBasicParsing).Content | Invoke-Expression

The script collects Operating System, Pester version and PowerShell version. You can open the URL in a browser to view the code before running it. --> Pester version : 5.3.0 PowerShell version : 5.1.19041.1237 OS version : Microsoft Windows NT 10.0.19043.0

closed time in 21 hours

bozho

issue commentpester/Pester

v5: BeforeAll and BeforeEach in different scopes execution order

Ah, I see... BeforeEach here runs before each test (It)... There's already an issue talking about this (#1219)

bozho

comment created time in 21 hours

issue openedpester/Pester

v5: BeforeAll and BeforeEach in different scopes execution order

<!-- Thank you for using Pester and taking the time to report this issue! Only Pester 4.10.x and 5.x.x are supported, try updating to the latest version to see if that solves your problem. See Installation and update guide.

  • Please update Pester and retest your code before submitting a bug report. See Installation and update guide.
  • Search for existing issues.
  • Pester 5 introduced breaking changes and some features were removed or are not yet migrated. See Breaking changes -->

General summary of the issue

I don't know if this is working as intended, or a bug. I have a test that would look like this:

Describe 'Description' {
    BeforeEach {
        # Do some expensive setup before each Context
        Write-Host 'BeforeEach'
    }

    Context 'Context 1' {
        BeforeAll {
            # Modify stuff loaded in BeforeEach above
            Write-Host 'BeforeAll 1'
        }

        It 'It 1.1' {
            ...
        }

        It 'It 1.2' {
            ...
        }
    }

    Context 'Context 2' {
        BeforeAll {
            # Modify stuff loaded in BeforeEach above
            Write-Host 'BeforeAll 2'
        }

        It 'It 2.1' {
            ...
        }

        It 'It 2.2' {
            ...
        }
    }
}

When I run the test, I get this:

BeforeAll 1
BeforeEach
BeforeAll 2
BeforeEach

If I change BeforeAlls to BeforeEach's, I get the expected order of execution, but I'd like to avoid running each Context's Before... block before each It inside the Context.

My expectation here would be that BeforeEach above runs before anything in each Context, and then each BeforeAll runs before all Its in a given Context.

Describe your environment

<!-- Please provide the output of this script: (Invoke-WebRequest -Uri "https://git.io/JTinj" -UseBasicParsing).Content | Invoke-Expression

The script collects Operating System, Pester version and PowerShell version. You can open the URL in a browser to view the code before running it. --> Pester version : 5.3.0 PowerShell version : 5.1.19041.1237 OS version : Microsoft Windows NT 10.0.19043.0

created time in 21 hours

issue commentpester/Pester

Passing external test script parameters to `InModuleScope`

@fflaten Brilliant, thank you! It's working, using the second approach.

I also realised InModuleScope returns whatever its script block returns, so I can capture a return value from a private function inside BeforeAll and simply use it in It blocks.

Thank you again!

bozho

comment created time in 4 days

issue commentpester/Pester

Passing external test script parameters to `InModuleScope`

I also tried doing something like, but it made no difference:

param (
    [Parameter()]
    [string] $ConfigurationPath
)

BeforeDiscovery {
    Import-Module -Name 'MyModule'
    $c = $ConfigurationPath
}

InModuleScope 'MyModule' -Parameters @{ ConfigurationPath = $c} {
    param(
        [Parameter()]
        [string] $ConfigurationPath
    )
bozho

comment created time in 5 days

issue openedpester/Pester

Passing external test script parameters to `InModuleScope`

<!-- Thank you for using Pester and taking the time to report this issue! Only Pester 4.10.x and 5.x.x are supported, try updating to the latest version to see if that solves your problem. See Installation and update guide.

  • Please update Pester and retest your code before submitting a bug report. See Installation and update guide.
  • Search for existing issues.
  • Pester 5 introduced breaking changes and some features were removed or are not yet migrated. See Breaking changes -->

General summary of the issue

I'm having trouble passing external test script parameters to InModuleScope.

Describe your environment

<!-- Please provide the output of this script: (Invoke-WebRequest -Uri "https://git.io/JTinj" -UseBasicParsing).Content | Invoke-Expression

The script collects Operating System, Pester version and PowerShell version. You can open the URL in a browser to view the code before running it. --> Pester version : 5.3.0 PowerShell version : 5.1.19041.1151 OS version : Microsoft Windows NT 10.0.19043.0

Steps to reproduce

<!-- Provide steps and/or sample code to reproduce the issue. Try to make it as concise as possible, removing irrelevant steps/code and providing sample data where possible. This will enable us to help you faster. Tip: Placing Powershell code in a codeblock like below makes it more readable.

    #My code

-->

My test script looks something like this:

param (
    [Parameter()]
    [string] $ConfigurationPath
)

BeforeDiscovery {
    Import-Module -Name 'MyModule'
}

InModuleScope 'MyModule' -Parameters @{ ConfigurationPath = $ConfigurationPath} {
    param(
        [Parameter()]
        [string] $ConfigurationPath
    )
    Describe 'Description' {
        Context 'Context' {
            BeforeAll {
                # Do something with $ConfigurationPath
            }

           It {
                ....
           }

I need BeforeAll to execute a private module function, so I need to be InModuleScope.

I create a Pester container with the correct parameter and pass it in when executing Invoke-Pester.

Expected Behavior

<!-- A clear and concise description of what you expected to happen. --> $ConfigurationPath in BeforeAll to have the script parameter value.

Current Behavior

<!-- What happens instead of the expected behavior. --> $ConfigurationPath in BeforeAll is $null.

If I remove InModuleScope, $ConfigurationPath inside BeforeAll is properly set (but then executing the private function fails, as expected).

created time in 5 days

issue closeddsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

I'm quite new with Pester and am giving it a go with testing our class-based DSC resources. I'm using Pester 5.3.0.

It looks like Pester does not/cannot mock PS functions executed from PowerShell class methods unless the class module is imported with using module statement.

So, assume we have a trivial class-based resource Foo and its Get() method executes Get-ChildItem. Copying some other community resources' tests, we'd go with something like this:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

function Invoke-TestSetup {
    Import-Module -Name DscResource.Test -Force -ErrorAction 'Stop'

    $script:testEnvironment = Initialize-TestEnvironment `
        -DSCModuleName $script:dscModuleName `
        -DSCResourceName $script:dscResourceName `
        -ResourceType 'Class' `
        -TestType 'Unit'
}

function Invoke-TestCleanup {
    Restore-TestEnvironment -TestEnvironment $script:testEnvironment
}

Invoke-TestSetup

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will fail, as Get() method does not seem to execute the mocked Get-ChildItem.

Now, if we replace the test setup with an appropriate using module statement:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

$scriptBody = "using module <path to module source>\$script:dscResourceName\$script:dscResourceName.psm1"
$script = [ScriptBlock]::Create($scriptBody)
. $script

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will pass, as Get() will call into the mocked function, which throws. The behaviour is the same for "regular" classes (not decorated with DSC resource attributes).

Lots of questions here :)

  • Am I missing something/doing something wrong?
  • Should this be considered a DscResource.Test bug?
  • Should I even be using DscResource.Test for this kind of testing?

Thank you!

closed time in 5 days

bozho

issue commentdsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

Ah... Please ignore this.

With Pester v5, Import-Module needs to be executed inside BeforeDiscovery block. Mocking PS functions works as expected then...

bozho

comment created time in 5 days

issue commentdsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

Ah, right... using module is present DnsRecordBase.tests.ps1 and ResourceBase.Tests.ps1...

I've had a look at Sampler, it looks a bit overkill for my needs, but I'll give it a go when I find some time :-)

The reason I went digging around is the original question: the trivial class example where PS functions called by class methods do not seem to be mocked in Pester v5 unless the class module is imported with using module. I see you use Pester v4 in DnsServerDsc, I'll try this example in v4.

BTW, is there a better place to discuss this issue?

bozho

comment created time in 5 days

push eventbozho/SqlServerDsc

Marko Bozikovic

commit sha 86ddb97a0cac3f7c9a2dbbed384c685b1f6654e8

[#1669] Post-rebase cleanup

view details

push time in 5 days

push eventbozho/SqlServerDsc

John McCall

commit sha ddc86c3b8e51666c16cc444ae184fff8a55400fe

SqlAgentAlert & SqlAgentFailsafe: Fix swapped README files (#1710) - SqlAgentAlert - Switched README file with SqlAgentFailsafe (issue #1709). - SqlAgentFailsafe - Switched README file with SqlAgentAlert (issue #1709).

view details

Johan Ljunggren

commit sha 96edad63a868533d39cbf0437b9f79403e030ab1

SqlServerDsc: Latest pipeline files and GitHub templates (#1711) - SqlServerDsc - Updated pipelines files to latest from Sampler project. - Updated GitHub issue templates.

view details

Eric Scheffler

commit sha 2bc90f3cfb7680551bd2bc1f437e9a598bbc3d97

SqlServerDsc: Issue 1712: CredScan password fix (#1716)

view details

Ankit Kumar

commit sha 059f8675d79996a8ef20a1363226689fd84bfec7

Update azure-pipelines.yml (#1715) - SqlServerDsc - Update HQRM tests to run on the VM image `windows-2022`. - Update unit tests to run on the VM image `windows-2022`. - Update integration tests to run both on Windows Server 2019 and Windows Server 2022 (issue #1713).

view details

Johan Ljunggren

commit sha 9b2c3f1dae88936ddfd1e260cfe0ab977878e20e

SqlRSSetup: Installing SSRS 2019 in integration test (#1718) - SqlRSSetup - Integration tests is now installing Microsoft SQL Server 2019 Reporting Services (issue #1717).

view details

Johan Ljunggren

commit sha 82db5c79fbbb8cab4050d5372c076346b8e57800

SqlRs: Integration test configures SSRS 2019 (#1719) - SqlRS - Integration tests now configures _Microsoft SQL Server 2019 Reporting Services_. - Fixed SSRS 2019 initialization ([issue #1509](https://github.com/dsccommunity/SqlServerDsc/issues/1509)). - Fix a problem that did not correctly evaluate the `UseSSL` property against the current state.

view details

dscbot

commit sha 8aa0a4c8c9c61881851f756fb92659812187d935

Updating ChangeLog since v15.2.0 +semver:skip (#1722)

view details

Marko Bozikovic

commit sha 9da31396f0871fa7e479efc7265fe77c88fa424f

[#1669] SqlLogin: LoginMustChangePassword, LoginPasswordExpirationEnabled and LoginPasswordPolicyEnforced parameters no longer enforce default values

view details

Marko Bozikovic

commit sha 70001bf6615d6df716066d93a30ffbf44c3dd3f8

[#1669] SqlLogin: Updated comment help

view details

Marko Bozikovic

commit sha 4a08cd986a09273b24ec49f17e930d4e75f9423e

[#1669] SqlLogin: added code coverage unit tests

view details

push time in 5 days

push eventbozho/SqlServerDsc

John McCall

commit sha ddc86c3b8e51666c16cc444ae184fff8a55400fe

SqlAgentAlert & SqlAgentFailsafe: Fix swapped README files (#1710) - SqlAgentAlert - Switched README file with SqlAgentFailsafe (issue #1709). - SqlAgentFailsafe - Switched README file with SqlAgentAlert (issue #1709).

view details

Johan Ljunggren

commit sha 96edad63a868533d39cbf0437b9f79403e030ab1

SqlServerDsc: Latest pipeline files and GitHub templates (#1711) - SqlServerDsc - Updated pipelines files to latest from Sampler project. - Updated GitHub issue templates.

view details

Eric Scheffler

commit sha 2bc90f3cfb7680551bd2bc1f437e9a598bbc3d97

SqlServerDsc: Issue 1712: CredScan password fix (#1716)

view details

Ankit Kumar

commit sha 059f8675d79996a8ef20a1363226689fd84bfec7

Update azure-pipelines.yml (#1715) - SqlServerDsc - Update HQRM tests to run on the VM image `windows-2022`. - Update unit tests to run on the VM image `windows-2022`. - Update integration tests to run both on Windows Server 2019 and Windows Server 2022 (issue #1713).

view details

Johan Ljunggren

commit sha 9b2c3f1dae88936ddfd1e260cfe0ab977878e20e

SqlRSSetup: Installing SSRS 2019 in integration test (#1718) - SqlRSSetup - Integration tests is now installing Microsoft SQL Server 2019 Reporting Services (issue #1717).

view details

Johan Ljunggren

commit sha 82db5c79fbbb8cab4050d5372c076346b8e57800

SqlRs: Integration test configures SSRS 2019 (#1719) - SqlRS - Integration tests now configures _Microsoft SQL Server 2019 Reporting Services_. - Fixed SSRS 2019 initialization ([issue #1509](https://github.com/dsccommunity/SqlServerDsc/issues/1509)). - Fix a problem that did not correctly evaluate the `UseSSL` property against the current state.

view details

dscbot

commit sha 8aa0a4c8c9c61881851f756fb92659812187d935

Updating ChangeLog since v15.2.0 +semver:skip (#1722)

view details

push time in 5 days

issue commentchocolatey/cChoco

cChocoSource does not update Source

@pauby Sorry for a late update.

@laoist gave a nice example of the problem.

Chocolatey does not support altering the URL. My patch removes and re-creates the source on URL changes.

bozho

comment created time in 5 days

issue commentdsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

@johlju Sorry to reopen, just wanted to check if I understand what you do in DnsServerDsc: your build process dumps all class' sources to DnsServerDsc.psm1 file, which is imported using Import-Module, and then you can use a simple using module DnsServerDsc in your tests, right?

We keep our class-based DSC resources in separate submodules and use NestedModules in the main manifest file. This approach makes the build essentially trivial, keeps modules nicely separated, but would make us use that ugly dynamic PowerShell to execute using module with a correct path for each submodule tested.

bozho

comment created time in 5 days

IssuesEvent

issue closeddsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

I'm quite new with Pester and am giving it a go with testing our class-based DSC resources. I'm using Pester 5.3.0.

It looks like Pester does not/cannot mock PS functions executed from PowerShell class methods unless the class module is imported with using module statement.

So, assume we have a trivial class-based resource Foo and its Get() method executes Get-ChildItem. Copying some other community resources' tests, we'd go with something like this:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

function Invoke-TestSetup {
    Import-Module -Name DscResource.Test -Force -ErrorAction 'Stop'

    $script:testEnvironment = Initialize-TestEnvironment `
        -DSCModuleName $script:dscModuleName `
        -DSCResourceName $script:dscResourceName `
        -ResourceType 'Class' `
        -TestType 'Unit'
}

function Invoke-TestCleanup {
    Restore-TestEnvironment -TestEnvironment $script:testEnvironment
}

Invoke-TestSetup

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will fail, as Get() method does not seem to execute the mocked Get-ChildItem.

Now, if we replace the test setup with an appropriate using module statement:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

$scriptBody = "using module <path to module source>\$script:dscResourceName\$script:dscResourceName.psm1"
$script = [ScriptBlock]::Create($scriptBody)
. $script

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will pass, as Get() will call into the mocked function, which throws. The behaviour is the same for "regular" classes (not decorated with DSC resource attributes).

Lots of questions here :)

  • Am I missing something/doing something wrong?
  • Should this be considered a DscResource.Test bug?
  • Should I even be using DscResource.Test for this kind of testing?

Thank you!

closed time in 5 days

bozho

issue commentdsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

Thank you, I'll have a look!

bozho

comment created time in 5 days

issue openeddsccommunity/DscResource.Test

`using module` for class-based DSC resource tests?

I'm quite new with Pester and am giving it a go with testing our class-based DSC resources. I'm using Pester 5.3.0.

It looks like Pester does not/cannot mock PS functions executed from PowerShell class methods unless the class module is imported with using module statement.

So, assume we have a trivial class-based resource Foo and its Get() method executes Get-ChildItem. Copying some other community resources' tests, we'd go with something like this:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

function Invoke-TestSetup {
    Import-Module -Name DscResource.Test -Force -ErrorAction 'Stop'

    $script:testEnvironment = Initialize-TestEnvironment `
        -DSCModuleName $script:dscModuleName `
        -DSCResourceName $script:dscResourceName `
        -ResourceType 'Class' `
        -TestType 'Unit'
}

function Invoke-TestCleanup {
    Restore-TestEnvironment -TestEnvironment $script:testEnvironment
}

Invoke-TestSetup

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will fail, as Get() method does not seem to execute the mocked Get-ChildItem.

Now, if we replace the test setup with an appropriate using module statement:

$script:dscModuleName = 'MyModule'
$script:dscResourceName = 'Foo'

$scriptBody = "using module <path to module source>\$script:dscResourceName\$script:dscResourceName.psm1"
$script = [ScriptBlock]::Create($scriptBody)
. $script

InModuleScope "Foo" {
    Describe "Description" {
        Context "My Context" {
            BeforeAll {
                Mock -CommandName Get-ChildItem -MockWith {
                    throw "BAR!"
                }
                $foo = [Foo]::new()
            }

            It "The Test" {
                { $foo.Get() } | Should -Throw
            }
        }
    }
}

The above test will pass, as Get() will call into the mocked function, which throws. The behaviour is the same for "regular" classes (not decorated with DSC resource attributes).

Lots of questions here :)

  • Am I missing something/doing something wrong?
  • Should this be considered a DscResource.Test bug?
  • Should I even be using DscResource.Test for this kind of testing?

Thank you!

created time in 11 days

pull request commentdsccommunity/SqlServerDsc

[#1509] SSRS 2019 initialization fix.

Hi @johlju,

Any chance you have a look at this, help me figure out the problems above?

Thank you!

bozho

comment created time in a month

issue commentwin-acme/win-acme

"Unknown parameter" error when ID starts with a hyphen

Hi @WouterTinus,

Sorry for a late reply. Single quotes do not work in cmd.exe (the parameter does get parsed as an ID value, but it's not matched to the existing ID). Escaping double quotes does work in cmd.exe.

Neither works in PowerShell.

What does work in PowerShell is:

wacs.exe --baseuri https://acme-staging-v02.api.letsencrypt.org --renew --force --id '\"-wZ5FfV0BekCaKjE33aQaiQ\"'

(so, single quotes with \-escaped double quotes).

May be worth adding to the documentation, to cover the edge case.

bozho

comment created time in 2 months

push eventbozho/SqlServerDsc

Marko Bozikovic

commit sha 249b0bba10e6b3d2b175f81db91a773cc9042f48

[#1669] SqlLogin: LoginMustChangePassword, LoginPasswordExpirationEnabled and LoginPasswordPolicyEnforced parameters no longer enforce default values

view details

Marko Bozikovic

commit sha a880cb3b3053b01218a6547ca86c803e638dc880

[#1669] SqlLogin: Updated comment help

view details

Marko Bozikovic

commit sha 68377555b7ec6501722cafb3301e5edf00b70b5c

[#1669] SqlLogin: added code coverage unit tests

view details

push time in 3 months

push eventbozho/SqlServerDsc

Johan Ljunggren

commit sha 48ecbd90e437f13f9a2f56240cd024e0435aa3eb

SqlSetup: Fix integration test (#1705) - SqlSetup - Fixed integration tests for SQL Server 2016 and SQL Server 2017.

view details

Johan Ljunggren

commit sha 630eeaeac8910da64edf7458c76d41d7bb3601fa

Fix codecov (#1706)

view details

Marko Bozikovic

commit sha d54f475c86698689dd542534f459478af4c2531d

[#1509] SSRS 2019 initialization fix.

view details

push time in 3 months

push eventbozho/SqlServerDsc

Johan Ljunggren

commit sha 48ecbd90e437f13f9a2f56240cd024e0435aa3eb

SqlSetup: Fix integration test (#1705) - SqlSetup - Fixed integration tests for SQL Server 2016 and SQL Server 2017.

view details

Johan Ljunggren

commit sha 630eeaeac8910da64edf7458c76d41d7bb3601fa

Fix codecov (#1706)

view details

push time in 3 months