如何在Powershell中进行TDD和单元测试？

随着MS将Powershell应用于所有新服务器产品中，我开始（勉强地）认为我需要认真对待它。TDD是“认真对待”的一部分。您是否找到了对Power Shell脚本进行单元测试的好方法？

我从极客噪声先生那里找到了嘲笑的样本-但我真的很喜欢RhinoMocks之类的东西。Brian Hartsock有一个来自MS Test的对Powershell字符串进行运行测试的示例。有点骇人听闻，但似乎可行。

我想要的是Powershell TDD体验，就像“真实”语言一样干净。

更新以澄清：

前两个答案试图使我远离测试Powershell。意见很有趣。我不想知道在Powershell中测试是否是个好主意。这是一个主观的问题，应该在其他论坛中提出。我想要一个对Powershell进行单元测试的解决方案。如果您认为这是个坏主意（可能是），请将其视为一个有趣的学术问题。

• 是的，脚本语言将不同的系统粘合在一起。但是，正如已经指出的那样，以动态语言模拟和破坏接缝也很容易。
• 我不是在问“调试”。调试是一个非常有用的主题。我让别人问。
• 也许PS脚本应该很简单。该语言支持模块化，并且不可避免地会在PS中实现复杂的流程（即使是一个不好的主意）。
• 这个问题的答案不是“您不能”。我可以看到（从链接的博客-有点旧了），有些人在解决该问题上取得了进展。

重新说明一下：如何以xUnit样式实现Powershell逻辑的自动化测试？ 集成测试很有趣，而打破依赖关系的单元测试最有趣。

Scott Muc启动了一个用于PowerShell的轻量级BDD框架项目Pester：

https://github.com/pester/Pester

现在，PsUnit已使用框架进行了更新。几个月前，我遇到了与您相同的问题，并且我觉得PsUnit对于要编写的脚本数量来说既庞大又复杂，所以我为PS编写了自己的单元测试框架。PS具有与其他脚本语言（例如python）相同的特征，例如，即使在测试方法中具有范围（对于模拟（又称为模拟））来说，也可以随时随地覆盖函数。也就是说，如果您要测试的函数或对象依赖于其他函数，则可以在测试方法中声明它们以创建本地伪造的实现。

因此，考虑选择哪种测试框架，我想说PS对TDD来说很容易。至少那是我的经验。

我认为您是在问“测试策略”而不是TDD，所以我将回答这两个问题。

在PowerShell中进行的大部分工作将通过cmdlet和对象管道集成许多不同的系统。如果您想确信自己的PowerShell脚本能正常工作，请尽最大努力构建一个完美的暂存环境，以便尽可能准确地测试所有这些系统。

与在TDD上“充实您的设计”或在事后进行单元测试“测试代码的意图”相比，在理想的暂存环境中运行脚本将具有更大的价值。

小注释可能会有所帮助：

• 该-whatif开关位于内置cmdlet中。我也发现您也可以这样做：-whatif:$someBool-您会在需要时知道。
• V2中的ISE具有调试器。甜。
• 您始终可以在C＃中编写自定义cmdlet，然后在其中执行任何操作。

讨论死气沉沉，但关切仍然存在。

考虑到单元测试PS的预期用途，我认为讨论中缺少一件事，因为它涉及企业系统中的模块。想象一下一个带有中央存储库的企业设置，用于在PS中实现常见的网络/文件级任务。在这种情况下，您将拥有少量的开发人员和网络专家，而他们的职责却有些重叠。开发人员创建了一个封装业务逻辑的模块，并立即确认了其有用性，因此其他人很快就介入了，并在自己的努力中整合了该模块。该模块包含在从一次性交互式脚本到中型客户端应用程序的所有内容中。尽管有些人可能不同意shell脚本语言的用例，但在该领域中，进化是不变的。

在这种情况下，我相信为这些要遵循的通用模块定义一组“合同”是有价值的。如果知识共享对于组织是必不可少的，那么修改这些模块的人可能不止一个。让单元测试验证模块的完整性将大大有助于维持秩序并最大程度地减少混乱，从而维持（也许增加）模块本身的价值。

至于首选方法，我尚未采用。PS让我想到了一种流体/动态/敏捷物质。将其包含在诸如我在TDD中看到的那样的刚性结构中感觉不自然。但是，鉴于上述情况，这个目标是不容忽视的。没关系，我很伤心，很抱歉浪费您的时间。感谢您的阅读。

我正在使用TDD编写一些基本的PowerShell脚本，例如以下模型：

首先，SUT_spec.ps1中的规范：

Import-Module -Name .\my_SUT.ps1

$case1_input=@{}
$case1_output=@{}
f1 $case1_input $case1_output

$case1_result = $case1_output["Output"] -eq "expected"
"f1 case1: $case1_result"

# repeat for all test cases

Remove-Module -Name my_SUT

其次，将my unit（SUT）作为my_SUT.ps1文件中的函数：

function f1($the_input, $the_output)
{
    #take input from $the_input hashtable, process it and put output into $the_output hashtable.

    $the_output["Output"]="results"
}

第三，可释放的主入口点是一个单独的文件，如SUT_spec.ps1，但带有来自实际外部源的输入。

从您的问题来看，我认为您将感到失望。Powershell只是一种命令行语言。当然，它可以执行C＃可以执行的任何操作，甚至可以执行更多操作，但是汇编语言也可以执行。当然，它也是面向对象的，并且已经连接到.NET库，但是C＃也是如此，它是一种更加简洁的语言。

如果解决方案的长度超过一个衬垫，或者您认为需要对其进行TDD，那么您就不想使用Powershell。这是一种充满惊奇的神秘语言，任何复杂的事物都应避免使用。

如果您想进行临时搜索并替换文本或设置其格式，或者在文件系统中四处查看，那么Powershell是您的朋友。您真正想做的是每天使用一点，并经常重复一遍，以保持对语法的熟悉。因此，也要避免使用开放源代码的Powershell库，而不必编写自己的CmdLets，除非您有非常专门的临时命令行用法。管道绑定规则是奥秘和丑陋的。

当然，这全都是我的意见，但是我是Powershell的长期用户，并且现在对它感到更加满意。