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

我已经开始研究整个单元测试/测试驱动的开发理念,我越是想到它,它似乎越充满静态类型检查的类似角色.这两种技术都可以为程序中的某些错误提供编译时快速响应检查.但是,如果我错了,请纠正我,但是看起来完全覆盖的单元测试套件会测试静态类型检查会测试的所有东西,然后是一些.或者说另一种方式,静态类型检查只是"证明"你的程序是正确的一部分,而单元测试将让你"证明"你想要的(在某种程度上).

那么,如果您使用单元测试,是否有任何理由使用静态类型检查的语言？有些类似的问题被问在这里,但我想进入更多的细节.静态类型检查具有哪些特定优势(如果有)超过单元测试？我想到了编译器优化和智能感知等一些问题,但这些问题还有其他解决方案吗？还有其他我没想过的优点/缺点吗？

软件质量有一个不可改变的事实.

如果无法编译,则无法发货

在此规则中,静态类型语言将赢得动态类型语言.

好的,是的,这个规则不是一成不变的.Web应用程序无需编译即可发布(我已部署了许多未编译的测试Web应用程序).但从根本上说是真实的

你越早发现错误,就越便宜

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

但为什么要这么麻烦？有很多非常聪明的人在那里以编译器的形式为您编写完整的错误检查系统.如果您担心错误很快就会使用静态类型语言.

请不要将这篇文章视为动态语言的抨击.我每天都使用动态语言并喜欢它们.它们具有令人难以置信的表现力和灵活性,并允许令人难以置信的迷人程序.但是在早期错误报告的情况下,它们确实输给了静态类型语言.

对于任何合理大小的项目,您只能通过单元测试来解释所有情况.

所以我的答案是"不",即使你设法解释所有情况,你也因此首先打败了使用动态语言的整个目的.

如果要编写类型安全的程序,最好使用类型安全的语言.

我认为自动单元测试对动态类型语言很重要,但这并不意味着它会替换您应用的上下文中的静态类型检查.事实上,一些使用动态类型的人实际上可能正在使用它,因为他们不想要经常进行类型安全检查的麻烦.

动态类型语言提供的优于静态类型语言的优势远不止于测试,类型安全仅仅是一个方面.与动态和静态类型语言相比,编程风格和设计差异也有很大差异.

此外,过于强烈地强制执行类型安全的单元测试意味着软件不应该是动态类型的,或者应用的设计应该用静态类型语言编写,而不是动态类型.