Powershell 中的同步单元测试执行
我有一个 Pester It 块,如下所示:
It "should add a header" {
{
$DifferenceObject = Get-Content -Path $PathToFile1
Set-PowershellFile -Path $PathToFile2
$ReferencedObject = Get-Content -Path $PathToFile2
Compare-Object -ReferenceObject $ReferencedObject -DifferenceObject $DifferenceObject | should -be $null
}
}
Set-PowershellFile 只是用一些新文本更新文件。我认为上面的代码会执行以下操作,但我只想确认一下:
- 它获取位于“PathToFile1”的文件的内容
- 它使用 Set-PowershellFile 将文件设置为“PathToFile2”,然后获取该文件的新内容。
- 将新更新的文件与第一个文件的内容进行比较,确保它们相同。
这是正确的吗?当我运行单元测试时,Set-PowershellFile 中所做的文件更改不会持续存在,但单元测试通过。我假设将此代码包装在 {} 中的 if 块内会导致同步行为,但不会“提交”文件更改。这一切都正确吗?
I've got a Pester It block, that looks like the below:
It "should add a header" {
{
$DifferenceObject = Get-Content -Path $PathToFile1
Set-PowershellFile -Path $PathToFile2
$ReferencedObject = Get-Content -Path $PathToFile2
Compare-Object -ReferenceObject $ReferencedObject -DifferenceObject $DifferenceObject | should -be $null
}
}
Set-PowershellFile just updates a file with some new text. I thought that the above code would do the following but I just want to confirm:
- It gets the content of a file located at 'PathToFile1'
- It sets the file at 'PathToFile2' using Set-PowershellFile, then gets the new content of that file.
- Compares the newly updated file to the content of the first file, making sure that they are the same.
Is this correct? When I run my unit tests, the file change made in Set-PowershellFile does not persist, but the unit test passes. I assumed that wrapping this code inside the if block in {} causes the synchronous behavior but doesn't 'commit' the file changes. Is this all correct?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
Mathias R. Jessen 在评论中提供了关键点 - 只需省略 内部的
{
和}
- 但由于我之前已经看到了潜在的误解,因此值得深入挖掘:虽然
{ ... }
块是大多数 PowerShell 语句的常规部分,例如foreach
和if
,单独它们不提供立即执行的作用域语句块,例如在 C# 中的工作方式。相反,
{ ... }
独立是 PowerShell 脚本块,即稍后执行的语句块,on需求,通过&
,调用运算符,用于在子范围中执行,或通过执行。
,点采购运算符< /a>,用于直接在原始范围中执行 - 可能是也可能不是调用者的范围(请参阅下面的警告)。因此,这样的脚本块文字必须保存在变量中或传递给需要脚本块的命令以便稍后执行 >。
如果没有的话,脚本块会隐式输出到成功输出流,默认情况下会转到控制台(主机),导致它由其
.ToString()
值,它只是脚本块的逐字内容,不包括分隔符({
和}
)。例如:
为了正确使用脚本块,您必须执行它,通常使用
&
:警告:
脚本块文字 - 与使用
[scriptblock]::Create('...')
- 与定义它们的范围域(也称为“会话状态”)相关联< /em>.这意味着:
在模块外部定义的脚本块文字,当也从模块外部调用时,会直接在 (
&
) / 的子作用域中运行在 (.
) 调用者的范围内。相比之下,在模块内部定义的脚本块文字与该模块的作用域域相关联,这意味着调用 - 无论在何处进行调用< em>from - 在该模块的顶级作用域(使用
.
)或其子作用域(使用&
)中执行。示例:
即,在使用
调用的非模块范围域中创建的脚本块。
直接在非模块调用者的范围内运行。也就是说,在使用
New-Module
创建并使用调用的动态模块的作用域中创建的脚本块。
,在该模块的顶级作用域中运行,即使它是从非模块调用者调用的。Mathias R. Jessen provided the crucial pointer in a comment - simply omit the inner
{
and}
- but since I've seen the underlying misconception before, it's worth digging deeper:While
{ ... }
blocks are a regular part of most PowerShell statements, such asforeach
andif
, in isolation they do not provide a scoped block of statements that are immediately executed, the way it would work in C#, for instance.Instead,
{ ... }
in isolation is the literal form of a PowerShell script block, i.e. a block of statements for later execution, on demand, either via&
, the call operator, for execution in a child scope of, or via.
, the dot-sourcing operator, for execution directly in the scope of origin - which may or may not be the caller's scope (see caveat below).Thus, such a script-block literal must either be saved in a variable or passed to a command expecting a script block in order to be executed later.
Absent that, a script block is implicitly output to the success output stream, which by default goes to the console (host), causing it to be rendered by its
.ToString()
value, which is simply the verbatim content of the script block, excluding the delimiters ({
and}
).For instance:
In order to use a script block properly, you must execute it, typically with
&
:Caveat:
Script-block literals - unlike script blocks constructed with
[scriptblock]::Create('...')
- are tied to the scope domain (a.k.a "session state") in which they are defined.This means:
Script-block literals defined outside a module, when also called from outside a module, do run in a child scope of (
&
) / directly in (.
) the caller's scope.By contrast, script-block literals defined inside a module, are tied to that module's scope domain, meaning that an invocation - irrespective of where the call is made from - execute in that module's top-level scope (with
.
) or a child scope thereof (with&
).Examples:
That is, the script block created in the non-module scope domain invoked with
.
ran directly in the non-module caller's scope.That is, the script block created in the scope domain of the dynamic module created with
New-Module
, invoked with.
, ran in that module's top-level scope, even though it was invoked from a non-module caller.