以语法错误为代价对空输入进行单元测试？答案

【问题标题】：Unit testing null inputs at the cost of syntax errors?以语法错误为代价对空输入进行单元测试？
【发布时间】：2020-06-29 12:07:28
【问题描述】：

我继承了一个项目，其中包含一些验证空输入的单元测试，即使在参数中明确说明它们是强制性的。

以下是生产代码的示例。

class Pasta {
  getIngredient(name: string) {
    if(name == null) {
      throw "need input"
    }
    console.log(name)
  }
}

var p = new Pasta()
p.getIngredient("noodles")
p.getIngredient()

我主要担心的是，在打字稿中执行此操作时，它会清楚地说明语法错误，因为函数 getIngredient() 需要输入一些内容。我知道全面测试是关键，但这甚至是必要的吗？它在 IDE 级别引发错误的事实意味着不应该这样做，但是为了全面性，该代码可以容忍错误，如果这是 Kotlin，它甚至不会编译。

我认为这些台词

    if(name == null) {
      throw "need input"
    }

甚至不需要它的测试。

如果您认为有必要，为什么会这样？谢谢。

【问题讨论】：

你的评估似乎是正确的——它闻起来像双重测试。也就是说，您可能希望默认的 null 输入行为是“需要输入”而不是一般的语法错误。

标签： typescript unit-testing

【解决方案1】：

当类型系统禁止null 进行测试时可能值得，但这在很大程度上取决于代码的使用方式。

如果代码由可能没有对他们的 JS 进行类型检查的客户使用（无论是通过 TypeScript 还是 Flow 或其他方式），那么 null 检查可能是一种快速失败并为客户提供有用反馈的有用方法。我怀疑这是将null 与string 进行比较是合法的原因，尽管我不是100% 的。如果您控制代码的所有潜在调用者并且始终是类型检查输入（也就是说，您没有显式强制转换或任何类型的转换），那么可以删除此类 null 检查。

不管怎样，同样的事情出现在 C# 中，带有可为空的引用类型（因为只有 C# 8+ 可以检查这些，并且大多数 C# 是 pre-8）和I subscribe to Jon Skeet's guidance that nullability checks still make sense in C# 8。

【讨论】：