Description of Issue

Restore-TestEnvironment could not handle Initialize-TestEnvironment added path.

Detail

Initialize-TestEnvironment adding current Test DSC Module's Root Path, which retrieved at here https://github.com/PowerShell/DscResource.Tests/blob/dev/TestHelper.psm1#L347, to the Machine's PSmodulePath at https://github.com/PowerShell/DscResource.Tests/blob/dev/TestHelper.psm1#L376

It's trying to pass $OldModulePath info, https://github.com/PowerShell/DscResource.Tests/blob/dev/TestHelper.psm1#L393 but ModuleRoot is remain afterRestore-TestEnvironment has ran.

Expectation

Should completely remove Test Module Path from PSModulePath.

https://github.com/PowerShell/DscResource.Tests/blob/master/Meta.Tests.ps1#L110

I often receive the following error when invoking pester testing when the DSCResource.Tests is included in the project:
[-] Error occurred in test script 'C:\projects\xnetworking\DscResource.Tests\Meta.Tests.ps1' 22.92s
Module installation of xDscResourceDesigner failed with exit code
at , C:\projects\xnetworking\DscResource.Tests\Meta.Tests.ps1: line 46

This error is completely random and only occurs about 50% of the time. If I Invoke the pester tests again it usually works correctly with no error. This wouldn't usually be too much of a problem, but the issue also occurs up in AppVeyor where I might not have permission to re-build a commit - unless I actually commit something - which is more of a problem.

This maybe a connection or download issue but I'm not sure. Any help would be appreciated!

When the same module is on the machine in multiple places some of the integration tests fail due to how we are currently setting up the test environment. This is fixed by ensuring only one copy of a module is on the machine, but we should have a better way of handling this scenario.

see:
https://github.com/PowerShell/DscResource.Tests/blob/master/TestHelper.psm1#L280

I've been looking through the Initialize-TestEnvironment method getting ready to retrofit this in to SharePointDsc and one of the questions I have about it for unit testing is why it sets up a custom path in the temp directory to save files in when Pester does the exact same thing already. In the cases of unit tests in SharePointDsc that we choose to not mock the file functions out, and in our integration tests, all of the path references point off to the TestDrive path. This gives us a fresh TestDrive that gets cleaned up between each Describe/Context block without it needing to be additional logic inside the DscResource.Tests scripts.

I don't see any harm in having it in there, but it does seem a touch redundant given the tool we use for testing already covers this off. Just wanted to throw it out there for discussion to see if there is a use case for this that I'm not seeing or if it's something that could be removed in favour of what Pester gives us natively.

Caused by line:
https://github.com/PowerShell/DscResource.Tests/blob/master/Meta.Tests.ps1#L64

This occurs because if:

$PSScriptAnalyzerModule | Import-Module -Force

is run more than once, the following errors occur:

If the PSScriptAnalyzer module is removed from memory then the tests will work again.

Also note the incorrect message in the Version System.Object[] line.

I'll take a look at these issues and raise some PR's for them.

Sorry about not documenting the issue fully, but I'm short on time today but wanted to make sure I didn't forget the problem.

Thanks

Here ls alias is used instead of Get-ChildItem and this breaks Text files formatting test on systems where this alias is removed (for example because git bash counterpart is used).

The following error occurs:

This has come up a number of times in peer review and would be nice to automate.

The Remove-Module code in Initialize-TestEnvironment is actually redundant. Import-Module -Force should be adequate to ensure the DSC Resource module is reloaded.

As noted by @narrieta in dsccommunity/ActiveDirectoryDsc#96 (comment)

Meta.Tests.ps1, line 430 at r5 (raw file):

            Context -Name $exampleFile.Name {

                try

If you see here I changed so this is run under an It-block.
https://github.com/PowerShell/xSQLServer/blob/dev/Tests/xSQLServerCommon.Tests.ps1#L37

Also added so it fails if the example does not contain an Example function.

Hi,

When running in an environment of least privilege, you cannot run DSC tests making use of TestHelper.psm1.

The helper attempts to make registry changes on line 373. My analysis seems to show that we don't need to make this change at a system level, for all future executions of PowerShell. My recommendation is to remove like 373. If removal cannot occur, then place the correct # requires statement to ensure that it is executed as an Administrator.

The script modifies the execution policy. Once again this creates issues on multiple levels. This logic should be removed, and recommendations made on how the environment should be setup.

There is also calls to install-module that need to be addressed as well.

• Create a common way for which repo can call pester (#90)
• fix style issues such as putting code blocks starts on new line (where possible). (#116)
• Add a common way to automatically detect code and non-code files for code coverage (#90)
• Add a way to override code and non-code coverage file detection filed #114
• Add a common way to convert Pester test results object into the code coverage visualizer format (I'm planning on using codecov.io, similarly to PowerShell\PowerShell) (#117)
• Add a common function to upload results to the code coverage visualizer (#117)
• Add deployment documentation(#117)

Detection of Repo root folder is not working correctly for xNetworking/SharePointDsc repositories:

This bug is in this code here:
https://github.com/PowerShell/DscResource.Tests/blob/dev/Meta.Tests.ps1#L18

This is only a problem for xNetworking/SharePointDsc

If the ".schema" in a *.schema.mof file is not all lower case the common tests - Script Resource Schema Validation will fail. See:
dsccommunity/NetworkingDsc#165 (comment)

Hi, PSScriptAnalyzer has just popped this up:

File C:\projects\xwebadministration\DscResource.Tests\DscResourceCommonTests\DscResourceCommonTests.psd1 contains 0x00 bytes. It's probably uses Unicode and need to be converted to UTF-8. Use Fixer 'Get-UnicodeFilesList $pwd | ConvertTo-UTF8'. File C:\projects\xwebadministration\DscResource.Tests\DscResourceTestHelper\DscResourceTestHelper.psd1 contains 0x00 bytes. It's probably uses Unicode and need to be converted to UTF-8. Use Fixer 'Get-UnicodeFilesList $pwd | ConvertTo-UTF8'.

and

File C:\projects\xwebadministration\DscResource.Tests\DscResourceCommonTests\DscResourceCommonTests.psd1 contains 0x00 bytes. It's probably uses Unicode and need to be converted to UTF-8. Use Fixer 'Get-UnicodeFilesList $pwd | ConvertTo-UTF8'. File C:\projects\xwebadministration\DscResource.Tests\DscResourceTestHelper\DscResourceTestHelper.psd1 contains 0x00 bytes. It's probably uses Unicode and need to be converted to UTF-8. Use Fixer 'Get-UnicodeFilesList $pwd | ConvertTo-UTF8'.

from https://ci.appveyor.com/project/PowerShell/xwebadministration/build/1.10.346.0

thanks

I will submit a PR to fix.

I think we might be running into a problem with the suppressed Example validation tests:
https://ci.appveyor.com/project/PlagueHO/xnetworking/build/3.1.513.0#L2202

They seem to output a test result value of "Pending" which AppVeyor is rejecting.

Looking at the message, Pending is not valid. The valid values are:
None, Running, Passed, Failed, Ignored, Skipped, Inconclusive, NotFound, Cancelled, NotRunnable

So I think we need to implement @TravisEz13 's improved suppression mechanism or use the -ExcludeTag 'Examples' mechanism instead.

The current script installs the module to the build slave. This can be troublesome because it requires administrative access and could potentially impact the build slave which is an issue if the same environment is re-used in unit testing. Using Save-Module to the current user profile and then deleting the folder on cleanup would be a nice approach.

I've recently been doing some work into creating custom PSSA rules. It should be fairly easy to create some rules that validate the Variable naming conventions (e.g. local variables start with lower case, parameter vars start with upper case).

The basis for the custom rule would be code like this:

process
{
    try
    {
        $Fucntions = $ScriptBlockAst.Ast.FindAll( { $args[0] -is [System.Management.Automation.Language.FunctionDefinitionAst] }, $true )
        foreach ($function in $functions)
        {
            $ParamNames = $Function.FindAll( { $args[0] -is [System.Management.Automation.Language.ParamBlockAst] }, $true ).Parameters.Name.VariablePath.UserPath
            $Variables = $Function.FindAll( { $args[0] -is [System.Management.Automation.Language.VariableExpressionAst] }, $true )
        }
    }
    catch
    {
        $PSCmdlet.ThrowTerminatingError( $_ )
    }
}

Needs a bit more work but it should be easy enough. If it is worth implementing, then I'm happy to submit a PR.

Test templates were moved to DscResources (https://github.com/powershell/dscresources ) repository, so all the links in that section need to be updated.

See this discussion for context.

The problem with Import-Module being inside the Intialize-TestEnvironment is that the DSC Resouce is loaded into the scope of the TestHelper.psm1 module. This means that tests for *-TargetResource have to be made inside an InModuleScope block.

@iainbrighton has tested the Import-Module cmdlet with -Scope Global set but it results in problems Mocking Get-TargetResource from the Test- and Set-TargetResource.

@narrieta has suggested the solution to this would be to move the Import-Module cmdlet from out of the Initialization and into the Unit Test header for each resource. Import-Module is found here.

This would be a breaking change for any resource unit and integration tests using the current test templates. Fixing these wouldn't be a major issue however but needs to be taken into account.

@KarolKaczmarek, @TravisEz13, @iainbrighton, @tysonjhayes?

If more that one error is detected by PSScriptAnalyzer test in meta.test.ps1 the text that is produced is not correctly formed:

The problem occurs here:
https://github.com/PowerShell/DscResource.Tests/blob/master/Meta.Tests.ps1#L147

This should be changed to something like this:

Write-Error -Message 'There are PSScriptAnalyzer errors that need to be fixed:'
@($PSScriptAnalyzerErrors).Foreach( { Write-Error -Message $_ } )
Write-Error -Message 'For instructions on how to run PSScriptAnalyzer on your own machine, please go to https://github.com/powershell/psscriptAnalyzer/'

I'll test and submit a PR.

Thanks!

The current resource test template updates the PSModulePath system variable for LCM to load the resource modules during integration tests. For unit tests, this is not necessary. Doing so and terminating a test without the test environment restore causes ISE to hang (while opening) when the added module path contains a folder that has multiple subfolders. For example, in of my tests, I had the resource modules for unit tests in C:\temp. The test preparation functions added C:\ to the PSModulePath system variable that caused ISE to scan the entire drive for modules.

For integration tests too, this need not be done. Instead, the modules can be copied over the existing module path and cleaned up later.

Right now it just warns, when it is run in AppVeyor (fails outside of AppVeyor)

This test should if a MOF file is set to UTF16.

See:
dsccommunity/WebAdministrationDsc#136 (comment)

for more context.

In the xDSCResourceDesigner module there is a function Test-xDscResource that tests if the resource fails many common tests including some warnings that the Get-TargetResource should return a hashtable and Test-TargetResource should return a boolen.

It would be quite nice if we tested this by default or at least pulled in a number of the functions into these tests to improve the quality of the code we are working on.

We should probably have a validation test for this.

This would allow for easy exclusion of specific test types when the repo is cloned in to other projects

Meta.Tests.ps1, line 439 at r5 (raw file):

                    $params = @{}
                    $command.Parameters.Keys | Where-Object { $_ -like "*Account" -or $_ -eq "Passphrase" } | ForEach-Object -Process {
                        $params.Add($exampleFile, $mockCredential)

I can't see this $mockCredential being assigned anywhere?

See
https://github.com/PowerShell/xSQLServer/blob/dev/Tests/xSQLServerCommon.Tests.ps1#L20

Meta.Tests.ps1, line 441 at r5 (raw file):

                        $params.Add($exampleFile, $mockCredential)
                    }
                    $null = Example @params -OutputPath "TestDrive:\" -ErrorAction Continue -WarningAction SilentlyContinue

Don't we need it to load with a dummy configuration ? Like -ConfigurationData $mockConfigurationData? or is this done in another way?
See https://github.com/PowerShell/xSQLServer/blob/dev/Tests/xSQLServerCommon.Tests.ps1#L51

This can be added later: I also have seen a need for using an example provided ConfigurationData block. It should look for $ConfigurationData variable after dot-sourcing the example. If it exist it should use that to run the example. If not, it should use the default $mockConfigurationData.

Currently we add

# Modify PSModulePath of the current PowerShell session. 
51 # We want to make sure we always test the development version of the resource 
52 # in the current build directory. 
53 if (($env:PSModulePath.Split(';') | Select-Object -First 1) -ne $pwd) 
54 { 
55     $env:PSModulePath = "$pwd;$env:PSModulePath" 
56 } 

Which in appveyor will add C:\project<repo_name>

Instead, we should be adding:

# Modify PSModulePath of the current PowerShell session.
# We want to make sure we always test the development version of the resource
# in the current build directory.
$script:oldPSModulePath = $env:PSModulePath
$pathToAdd = Split-Path $pwd -Parent
if (($env:PSModulePath.Split(';') | Select-Object -First 1) -ne $pathToAdd)
{
    $env:PSModulePath = "$pathToAdd;$env:PSModulePath"
}

which would add C:\project (containing folder with the DSC resource module).

Another issue is that we should be also reverting value of $env:PSModulePath to the original value after the tests.

The Meta.Tests.ps1 test does not handle empty files and fails with a meaningless error when it comes across one.

There is a StyleGuideline that states that Egyptian Braces shouldn't be used - e.g. code block open braces should appear on a new line.

It would be good if Meta.Tests.ps1 could include a test identified this problem.

Ideally, an automatic fixer for this could also be provided in Meta.Fixers.ps1.

WMF 5.0 no longer a requirement of PSSA. v1.4.0 supports WMF 3.0 and above.

I'll submit a PR if agreeable?

Using either the code in the appveyor.yml template most projects started with or the code in #85 the test results fail to upload.
You can see this at https://ci.appveyor.com/project/PlagueHO/xNetworking/build/tests is empty. It started with Pester 4.0.2 as mention in pester/Pester#571 (comment).

I know how to resolve this. We should also ask if AppVeyor can fix this.

In the xSQLServer repo the README.md currently have long lines and using the same header several times (like PSDscResource).

MD013
https://ci.appveyor.com/project/johlju/xsqlserver/build/5.0.342.0#L864
MD024
https://ci.appveyor.com/project/johlju/xsqlserver/build/5.0.342.0#L1139

We have three options as I see it (not taking in account changing the README.md).

1. Add MD013 and MD024 to the .markdownlint.json file in this module.
2. Change the code so it uses the .markdownlint.json in the module being tested if it exist. I guess this line need to do change https://github.com/PowerShell/DscResource.Tests/blob/dev/gulpfile.js#L21 with some logic :)
3. I workaround it by parsing in the additional MD013 and MD024 in the .markdownlint.json after cloning DscResource.Tests in AppVeyor.yml.

I personally like option 2.

Hi, this path seems incorrect now:

# Load the TestHelper module which contains the *-ResourceDesigner functions Import-Module -Name (Join-Path -Path $PSScriptRoot -ChildPath 'TestHelper.psm1') -Force

as this is thrown

Import-Module : The specified module 'C:\projects\xwebadministration\DscResource.Tests\DscResourceCommonTests\TestHelper.psm1' was not loaded because no valid module file was found in any module directory. At C:\projects\xwebadministration\DscResource.Tests\DscResourceCommonTests\Meta.Tests.ps1:22 char:1

from

https://ci.appveyor.com/project/PowerShell/xwebadministration

thanks

Recently when I submitted a pull request for changes to the xExchange module, the automated tests failed on a couple files, and suggested running Get-TextFilesList | ConvertTo-SpaceIndentation to fix them. I decided to run this against the entire module, instead of just the files it suggested. After doing so and resubmitting the pull request, I got failures in multiple files that weren't otherwise modified other than running these commands against them. The failures are reported here:

https://ci.appveyor.com/project/PowerShell/xexchange/build/1.0.35

One of the files that broke is located here:

https://github.com/PowerShell/xExchange/blob/dev/DSCResources/MSFT_xExchMailboxDatabase/MSFT_xExchMailboxDatabase.psm1

Currently the Initialize-TestEnvironment code changes the PSModuleRoot path to ensure that the correct module is tested. It is changed at the machine level to ensure that the correct path is set during Integration testing. However it should only be changed at the Process level for Unit tests.

These lines:
line https://github.com/PowerShell/DscResource.Tests/blob/master/TestHelper.psm1#L357
https://github.com/PowerShell/DscResource.Tests/blob/master/TestHelper.psm1#L419
should be wrapped in a check so that they only fire when $TestType = 'integration'

As noted by @narrieta in dsccommunity/ActiveDirectoryDsc#96 (comment)

There should be a file in each repo that says which common tests the repo has passed. Those are treated as an error. Once someone gets that test passing they add the test to the file so that regressions will cause a failure.

Currently the PSScriptAnalyzer test in Meta.tests.ps1 only evaluates Error level rules. However, there are some PSSA Warning level rules that would also be valuable if they failed on for DSC Resources.

Rules

Some PSSA Warning level rules are should not be applied to DSC resources because they don't make sense for DSC. The following rules I think should not be run:

PSUseShouldProcessForStateChangingFunctions
PSMissingModuleManifestField - this one is triggered because some of the modules contain language data files *.psd1 and PSSA is treating them as manifest files and reporting that version number and other parameters are missing.
PSAvoidUsingInvokeExpression

Coverage

PSSA is currently running against the entire root folder of the resource module (which includes tests and examples folders). From my initial tests a lot of failures are occurring in the tests and examples folders.

Suggestion: Only run the PSSA tests against the DSCResource folder in each module for now and look at extending it. Also, the tests are getting run on the DSCResource.tests folder which seems unnecessary. Some of the larger resource modules also take quite a long time (10-20 minutes) running PSSA so reducing the coverage to only the resource code might be a good idea for now.

Output from running warning level against xNetworking\DSCResource folder:

RuleName                            Severity     FileName   Line  Message
--------                            --------     --------   ----  -------
PSUseShouldProcessForStateChangingF Warning      MSFT_xDnsC 124   Function ’Set-TargetResource’ has verb that could change
unctions                                         onnectionS       system state. Therefore, the function has to support
                                                 uffix.psm1       'ShouldProcess'.
PSPossibleIncorrectComparisonWithNu Warning      MSFT_xFire 658   $null should be on the left side of equality comparisons.
ll                                               wall.psm1
PSPossibleIncorrectComparisonWithNu Warning      MSFT_xFire 540   $null should be on the left side of equality comparisons.
ll                                               wall.psm1
PSPossibleIncorrectComparisonWithNu Warning      MSFT_xFire 286   $null should be on the left side of equality comparisons.
ll                                               wall.psm1
PSAvoidUsingInvokeExpression        Warning      MSFT_xFire 628   Invoke-Expression is used. Please remove Invoke-Expression
                                                 wall.psm1        from script and find other options instead.
PSAvoidUsingInvokeExpression        Warning      MSFT_xFire 627   Invoke-Expression is used. Please remove Invoke-Expression
                                                 wall.psm1        from script and find other options instead.
PSAvoidUsingInvokeExpression        Warning      MSFT_xFire 326   Invoke-Expression is used. Please remove Invoke-Expression
                                                 wall.psm1        from script and find other options instead.
PSAvoidUsingInvokeExpression        Warning      MSFT_xFire 131   Invoke-Expression is used. Please remove Invoke-Expression
                                                 wall.psm1        from script and find other options instead.
PSAvoidUsingInvokeExpression        Warning      MSFT_xFire 120   Invoke-Expression is used. Please remove Invoke-Expression
                                                 wall.psm1        from script and find other options instead.
PSUseSingularNouns                  Warning      MSFT_xFire 578   The cmdlet 'Test-RuleProperties' uses a plural noun. A
                                                 wall.psm1        singular noun should be used instead.
PSUseShouldProcessForStateChangingF Warning      MSFT_xNetB 161   Function ’New-TerminatingError’ has verb that could change
unctions                                         IOS.psm1         system state. Therefore, the function has to support
                                                                  'ShouldProcess'.
PSUseShouldProcessForStateChangingF Warning      MSFT_xNetB 63    Function ’Set-TargetResource’ has verb that could change
unctions                                         IOS.psm1         system state. Therefore, the function has to support
                                                                  'ShouldProcess'.
PSMissingModuleManifestField        Warning      MSFT_xNetB 1     The member 'ModuleVersion' is not present in the module
                                                 IOS.psd1         manifest. This member must exist and be assigned a version
                                                                  number of the form 'n.n.n.n'. Add the missing member to the
                                                                  file 'C:\Users\Daniel\Source\GitHub\xNetworking\DSCResources
                                                                  \MSFT_xNetBIOS\en-US\MSFT_xNetBIOS.psd1'.
PSUseShouldProcessForStateChangingF Warning      MSFT_xNetw 43    Function ’Set-TargetResource’ has verb that could change
unctions                                         orkTeam.ps       system state. Therefore, the function has to support
                                                 m1               'ShouldProcess'.
PSMissingModuleManifestField        Warning      MSFT_xNetw 1     The member 'ModuleVersion' is not present in the module
                                                 orkTeam.ps       manifest. This member must exist and be assigned a version
                                                 d1               number of the form 'n.n.n.n'. Add the missing member to the
                                                                  file 'C:\Users\Daniel\Source\GitHub\xNetworking\DSCResources
                                                                  \MSFT_xNetworkTeam\en-US\MSFT_xNetworkTeam.psd1'.
PSUseDeclaredVarsMoreThanAssigments Warning      MSFT_xRout 431   The variable 'Subnet' is assigned but never used.
                                                 e.psm1
PSUseShouldProcessForStateChangingF Warning      MSFT_xRout 95    Function ’Set-TargetResource’ has verb that could change
unctions                                         e.psm1           system state. Therefore, the function has to support
                                                                  'ShouldProcess'.

When using the template for the integration test. The first thing the script template does is download a DscResource.Test directory which contains TestHelper.psm1 from GitHub. The template script calls TestHelper.psm1 which throws error because it can’t locate the module manifest file which is located in the root folder of the module. TestHelp.psm1 is looking for this file in the Tests\Integration folder. TestHelper.psm1 is using $MyInvocation.MyCommand.Path to get the path to the module manifest. $MyInvocation.MyCommand.Path is going to resolve to whatever folder TestHelper.psm1 is located it. This goes against the testing guidance to create a Tests\Integration folder as the test will only run without error if they ran from the root of the module.

This is related to #103

In https://github.com/PowerShell/DscResource.Tests/blob/master/Meta.Tests.ps1 the "Files encoding" test test if all of the files are encoded in UTF-8.

Is this a best practice for module manifest files ? I'm wondering because New-Modulemanifest doesn't create the manifest in UTF-8.

Getting wrong output at the end of the tests I think; System.Management.Automation.PSCustomObject

[Build Info] [02/07/2017 18:42:14] Test result Type: System.Management.Automation.PSCustomObject

https://ci.appveyor.com/project/PowerShell/xsqlserver/build/5.0.838.0#L5389

Description

Initialize-TestEnvironment will failed to change Execution policy if Box is joined to Domain.

Exception

When you run like other DSC Resource doing, you will get Security Error on L383

# Initialize
[String] $moduleRoot = Split-Path -Parent (Split-Path -Parent (Split-Path -Parent $Script:MyInvocation.MyCommand.Path))
if ( (-not (Test-Path -Path (Join-Path -Path $moduleRoot -ChildPath 'DSCResource.Tests'))) -or `
     (-not (Test-Path -Path (Join-Path -Path $moduleRoot -ChildPath 'DSCResource.Tests\TestHelper.psm1'))) )
{
    & git @('clone','https://github.com/PowerShell/DscResource.Tests.git',(Join-Path -Path $moduleRoot -ChildPath '\DSCResource.Tests\'))
}
else
{
    & git @('-C',(Join-Path -Path $moduleRoot -ChildPath '\DSCResource.Tests\'),'pull')
}
Import-Module (Join-Path -Path $moduleRoot -ChildPath 'DSCResource.Tests\TestHelper.psm1') -Force
$TestEnvironment = Initialize-TestEnvironment -DSCModuleName $global:dscModuleName -DSCResourceName $global:dscResourceName -TestType Unit

Initializing Test Environment for Unit testing of Grani_CredentialManager in module GraniResource.
DSC Module Manifest 'GraniResource.psd1' detected in folder 'D:\Github\guitarrapc\GraniResource'.
[-] Error occurred in test script 'D:\Github\guitarrapc\GraniResource\Test\Grani_CredentialManager\Grani_CredentialManager.Tests.ps1' 1.29s
  Security error.
  at Initialize-TestEnvironment, D:\Github\guitarrapc\GraniResource\DSCResource.Tests\TestHelper.psm1: line 383

Reason

Issue happen when Domain Joined machine, or any other condition may apply, had restricted to change ExecutionPolicy. You can reproduce error by following on Domain Joined Box.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the
about_Execution_Policies help topic at http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope.  Due to the ove
rride, your shell will retain its current effective execution policy of Bypass. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information pl
ease see "Get-Help Set-ExecutionPolicy".
At line:1 char:1
+ Set-ExecutionPolicy -ExecutionPolicy Unrestricted
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
    + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

Proposal fix

You can avoid issue by just change execution policy to only current Process. As this function aim to remove any side-effect with Test, I propose limit to current process is much better.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -Force