自动化单元测试能否取代静态类型检查?

关于软件质量,有一个不变的事实。

如果它不能编译,就不能发送

在这个规则中,静态类型的语言将胜过动态类型的语言。

越早发现错误,修复的成本就越低

静态类型的语言将防止在软件开发周期中最早可能出现的某个时刻发生真正的错误。一种动态的语言不会。单元测试,如果你是彻底到超人的水平,可以取代静态类型语言。

请不要把这篇文章看作是对动态语言的抨击。我每天都使用动态语言,而且我喜欢它们。它们具有难以置信的表现力和灵活性,并允许令人难以置信的编程。然而,在早期错误报告的情况下,它们确实输给了静态类型语言。

对于任何规模合理的项目,您不能仅用单元测试来解释所有情况。

所以我的答案是“不”,即使你设法解释了所有的情况,你也因此从一开始就挫败了使用动态语言的全部目的。

如果您想编程类型安全,最好使用类型安全语言。

重要的 但这并不意味着它将取代应用上下文中的静态类型检查。事实上,一些使用动态类型的人实际上可能正在使用它,因为他们确实在使用它 想要经常进行安全检查的麻烦。

与静态类型语言相比,动态类型语言提供的优势远远超出了测试,类型安全只是一个方面。与动态和静态类型语言相比,编程风格和设计差异也大不相同。

拥有100%的代码覆盖率并不意味着您已经对应用程序进行了全面测试。考虑下面的代码:

if (qty > 3)
{
    applyShippingDiscount();
}
else
{
    chargeFullAmountForShipping();
}

如果我输入qty=1和qty=4的值,我可以获得100%的代码覆盖率。

现在想象一下,我的经营状况是:“……对于3件或3件以上的订单,我将对运输成本给予折扣……”。然后,我需要编写在边界上工作的测试。所以我会设计数量为2,3和4的测试。我仍然有100%的覆盖率,但更重要的是,我在逻辑中发现了一个缺陷。

这就是我只关注代码覆盖率的问题。我认为,在最好的情况下,开发人员会根据业务规则创建一些初始测试。然后,为了提高覆盖率,他们在设计新的测试用例时引用了自己的代码。

人们还倾向于忘记声明类型作为文档的价值。例如,如果Java方法返回 List<String>

声明局部变量类型的值要低得多,因为在编写良好的代码中,变量的存在范围应该很小。但是,您仍然可以使用静态类型:您不需要声明类型,而是让编译器推断它。语言如 Scala 甚至 C# 允许你这样做。

QuickCheck ScalaCheck 根据规范生成测试,尝试猜测重要边界。

我会用另一种方式来描述它——如果你没有静态类型的语言,你有 如果你打算用这些代码做任何“真实的”事情,就要进行非常彻底的单元测试。

也就是说,静态类型(或者更确切地说,显式类型)比单元测试有一些显著的好处,这让我更喜欢它。它创建了更易于理解的API,并允许快速查看应用程序的“框架”(即每个模块或代码段的入口点),这种方式对于动态类型语言来说要困难得多。

总而言之:在我看来,考虑到可靠、彻底的单元测试,在动态类型语言和静态类型语言之间的选择主要是一种尝试。有些人更喜欢一个;其他人更喜欢其他人。使用正确的工具进行作业。但这并不意味着它们是相同的——静态类型的语言在某些方面总是有优势,而动态类型的语言在某些不同方面总是有优势。单元测试在最大程度上减少了动态类型语言的缺点,但并没有完全消除它们。

但这并不是最重要的问题,最重要的问题是:不能这样重要吗?

我想如果你非常仔细的话,可能会的。但是为什么要麻烦呢?如果语言已经在检查以确保静态类型是正确的,那么测试它们就没有意义了(因为您可以免费获得它)。

对于javascript,我希望jsLint将发现几乎所有的类型检查问题。主要是通过建议替代编码风格来减少曝光。

类型检查有助于强制执行合同 之间 系统中的组件。单元测试(顾名思义)验证 内部的 组件的逻辑。

对于单个代码单元,我认为单元测试确实可以使静态类型检查变得不必要。但在一个复杂的系统中,自动化测试无法验证系统中不同组件可能交互的所有方式。为此,使用 接口