测试期望
本页介绍我们对添加到 Dynamo 中的新代码进行测试时所查找的内容。
因此，您有一个要添加的新节点。太棒了。是时候添加一些测试了。这样做有两个原因。
这有助于找出它不起作用的地方
当其他人更改了破坏节点的内容时，它应该会破坏测试。这样，那个破坏测试的人就需要去修复它。如果它没有破坏测试，那么处理破坏模型的用户在很大程度上是您的问题。
Dynamo 中的测试主要分为两种类型：单元测试、系统测试。
单元测试
应尽可能少地进行单元测试。如果通过 C# Zero Touch 节点生成一个计算平方根的节点，则测试应仅测试该 dll，并直接对该代码进行 C# 调用。单元测试甚至不应包括 Dynamo。
它应该包括：
阳性测试（它做了正确的事情）
阴性测试（当给予垃圾输入时它不会吠叫）
回归测试（当有人在代码中发现错误时，编写测试以确保它不会再次发生）
它们应该小巧、快速且可靠。大多数测试应该是单元测试。
系统测试
系统测试在多个组件上运行，并测试它们如何组合在一起。它们应该小心使用和制作。
为什么？它们的运行成本很高。我们需要让测试套件以尽可能少的延迟运行。
在编写系统测试时，首先要做的是查看此图并找出您要涵盖的子系统。
理想情况下，将有一系列渐进式测试，涵盖越来越多的交互块集，因此当测试开始失败时，可以很快找出问题所在。
需要系统测试的内容示例：
一种新型 Revit 节点，用于在跟踪中存储多个元素而不是单个元素
以不同方式显示数据的新 Watch 节点
不需要系统测试的示例：
新数学节点
字符串处理库
系统测试应该：
断言正确的行为
断言没有病态行为，例如没有例外
Last updated