69

随着 MS 将 powershell 推入所有新的服务器产品，我开始（不情愿地）认为我需要认真对待它。“认真对待”的一部分是 TDD。您是否找到了对 power shell 脚本进行单元测试的好方法？

我从Geek Noise 先生那里找到了嘲笑的样本——但我真的很喜欢RhinoMocks之类的东西。Brian Hartsock有一个来自 MS Test 的 powershell 字符串运行测试示例。有点hacky，但它似乎工作。

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

更新澄清：

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

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

重新声明：您如何以 xUnit 的风格实现 Powershell 逻辑的自动化测试？ 集成测试很有趣，打破依赖关系的单元测试最有趣。

4

6 回答 6

44

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

https://github.com/pester/Pester

于 2011-01-04T21:31:57.883 回答
11

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

因此，无论您选择使用哪种测试框架，我都会说 PS 非常容易进行 TDD。这至少是我的经验。

于 2009-08-21T05:21:50.190 回答
3

我想你问的是“测试策略”而不是专门的 TDD，所以我会回答这两个问题。

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

在完美的暂存环境中运行脚本将比通过 TDD “充实你的设计”或通过事后单元测试“测试代码的意图”更有价值。

可能有帮助的小笔记：

  • 该-whatif开关存在于内置 cmdlet 上。另外我刚刚发现你也可以这样做：-whatif:$someBool- 你会知道什么时候需要它。
  • V2 中的 ISE 有一个调试器。甜的。
  • 您始终可以在 C# 中编写自定义 cmdlet 并在那里做任何您想做的事情。
于 2009-06-02T20:54:56.010 回答
1

我正在使用 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

其次，我的单位（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，但输入来自实际外部源。

于 2019-09-25T10:57:31.807 回答
0

死的讨论，但担忧是非常活跃的。

鉴于 PS 的预期用途涉及到企业系统中的模块，我在讨论单元测试 PS 的有用性时发现缺少的一件事。想象一个企业环境，它有一个中央存储库，用于在 PS 中实现的常见网络/文件级任务。在这种情况下，您有少量的开发人员和网络专家，他们的职责都略有重叠。开发人员创建了一个封装业务逻辑的模块，并且它的有用性立即得到承认，因此其他人很快就会加入并在他们自己的工作中加入该模块。该模块包含在从一次性交互式脚本到中型客户端应用程序的任何内容中；虽然有些人可能不同意 shell 脚本语言的用例，但在这个领域进化是一个常数。

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

至于首选的方法，我还没有采用。PS 让人想起流体/动态/敏捷的物质。将它包含在一个僵化的结构中，就像我在 TDD 中看到的那样，感觉很不自然。但是，鉴于上述情况，这个目标不容忽视。没关系，我很伤心，很抱歉浪费你的时间。感谢您的阅读。

于 2012-05-25T14:02:58.187 回答
-4

从你的问题来看，我认为你正在走向失望。Powershell 只是一种小小的命令行语言。当然，它可以做 C# 可以做的任何事情，甚至更多，但汇编语言也可以。当然，它也是 OO 并与 .NET 库挂钩，但 C# 也是如此，它是一种更简洁的语言。

如果一个解决方案比一个班轮更长，或者您认为您需要对它进行 TDD，那么您就不想使用 Powershell。这是一种充满惊喜的神秘语言，任何复杂的事情都应该避免。

如果您想做一些特别的搜索和替换或格式化文本，或者在您的文件系统中查看，那么 Powershell 是您的朋友。您真正想做的是每天使用一点，并经常重复自己，以便熟悉语法。出于这个原因，还要避免使用开源 Powershell 库，并且忘记编写自己的 CmdLets，除非您有一个非常专门的临时命令行使用案例。管道绑定规则晦涩难懂。

当然，这只是我的观点，但我是 Powershell 的长期用户，现在我对它更满意了，因为我是这样看待它的。

于 2009-06-02T18:32:31.647 回答