厌倦了用非语义测试来弥补动态类型 - 建议吗？

在开始学习计算机工程之前，我曾经使用 Rails（之前是 PHP）进行了大量的 Web 编程。

从那时起，我用 C 完成了很多学校作业，并用 Objective-C（Mac 的东西）完成了一些个人工作。我学会了喜欢静态类型。

但现在我不得不做一些专业的 Web 开发（自由职业），并再次选择了 Rails。我发现编写非语义类型检查测试真的很烦人。我从 C 和 Objective-C 编译器免费获得这些。我喜欢点击“构建”，让系统检查我的所有代码，看看 A 可以调用 B，B 可以调用一些晦涩的库 C，等等。我所要做的就是测试语义。但对于 Rails，我是编译器。 :(

有人走过同样的路吗？我使用 C# 和 Java + x 框架进行 Web 开发 ASP.NET MVC 是唯一的选择吗？寻找一些建议，甚至一些同情......：P

顺便说一句，我特别提到了 Rails 而不是 Ruby，因为我不介意 Ruby 对于简单的东西（例如脚本编写或其他）的动态特性。但由于 Rails 依赖于如此多的 gem，并且通常会添加许多其他 gem，因此动态类型成为一个问题。

Thanks!

edit:

我遵循了 pst 的建议并研究了 Scala。在阅读该语言的创建者 Martin Odersky 所著的《Scala 编程》一书时，我看到了这段文字，它在很多方面表达了我的担忧以及更多的想法。非常有趣的阅读。

摘自 Martin Odersky 的《Scala 编程》第 52 页：

Scala 是静态类型的

静态类型系统分类 变量和表达式根据 他们持有的价值观类型以及 计算。 Scala 脱颖而出 具有非常先进的静态语言 类型系统。从一个系统开始 嵌套类类型很像 Java 的， 它允许您参数化类型 与泛型，使用组合类型 交叉点，并隐藏细节 使用抽象类型的类型。这些给 为建设和建设奠定了坚实的基础 编写您自己的类型，以便您 可以设计接口 同时使用安全灵活。

如果您喜欢动态语言，例如 Perl、Python、Ruby 或 Groovy，您都可以 可能会觉得有点奇怪 Scala 的静态类型系统列出 作为其优点之一。后 所有，缺少静态类型 系统被一些人引用为 动态语言的主要优点。 最常见的反对论点 静态类型是他们制作的 程序太冗长，防止 程序员不表达自己 如他们所愿，并使不可能 某些动态模式 软件系统的修改。

然而，这些论点往往并不 违背静态类型的想法 一般，但针对特定类型 系统，这些系统被认为太 冗长或太不灵活。为了 例如，艾伦·凯（Alan Kay）， Smalltalk 语言曾经说过： “我并不反对类型，但我不 知道任何类型系统不是 彻底的痛苦，所以我还是喜欢动态 打字。”

我们希望通过这本书让您信服 Scala 的类型系统远非如此 是一种“彻底的痛苦”。事实上，它 很好地解决了两个常见问题 关于静态类型的担忧： 通过类型避免冗长 获得推理和灵活性 通过模式匹配和一些 编写和组合类型的新方法。 排除了这些障碍之后， 静态类型的经典优点 系统可以得到更好的欣赏。 其中最重要的是 好处是可验证的属性 程序抽象，安全 重构，更好 文档。

可验证的属性

静态类型系统可以证明 不存在某些运行时错误。 例如，他们可以证明 诸如以下属性：布尔值永远不会 添加到整数；私有变量 不能从其外部访问 班级;函数被应用到 正确数量的参数；仅有的 字符串曾经被添加到一组 字符串。

未检测到其他类型的错误 通过今天的静态类型系统。为了 例如，他们通常不会检测到 非终止函数、数组 边界违规或划分 零。他们也不会检测到 你的程序不符合它的 规范（假设有一个 规格，就是这样！）。静态类型系统 因此被一些人驳回 因为不是很有用。论点 因为这样的类型系统可以 只检测简单的错误，而 单元测试提供了更广泛的 覆盖率，为什么要费心静态类型 根本吗？

我们认为这些论点忽略了 重点。虽然是静态类型 系统当然不能替代单位 测试，可以减少 需要照顾的单元测试 一些属性，否则会 需要进行测试。同样，单位 测试不能取代静态类型。 毕竟，正如 Edsger Dijkstra 所说， 测试只能证明存在 错误，永远不会缺席。所以 保证静态类型给出 可能很简单，但它们是真实的 形式的担保，金额不限 测试可以交付。

安全重构

静态类型系统提供了 让您做出改变的安全网 到具有高度的代码库 信心。例如考虑一个 重构增加了一个额外的 方法的参数。在静态 您可以更改输入的语言， 重新编译你的系统并简单修复 所有导致类型错误的行。 一旦你完成了这个，你 肯定已经找到了所有的地方 需要改变。这同样适用于 许多其他简单的重构，例如 更改方法名称，或移动 方法从一个类转移到另一个类。在 所有情况下都会进行静态类型检查 提供足够的保证，使新的 系统就像旧的一样工作。

文档

静态类型是程序文档 由编译器检查 正确性。与普通的评论不同的是， 类型注释永远不能超出 日期（至少不是如果源文件 包含它的最近通过了 编译器）。此外，编译器和 集成开发环境 可以利用类型注释 提供更好的上下文帮助。为了 以综合开发为例 环境可以显示所有 可供选择的成员 确定静态类型 选择的表达式 制作并查找所有成员 那种类型。

这是我对动态语言的“抱怨”之一。我想测试语义，而不是类型错误；-) 话虽如此，在所有重要情况下，良好的测试框架/设置确实是必须的，良好的代码覆盖率和测试的需求也很重要。

如果您确实想沿着 JVM 上的静态类型路径（我已经这样做了），我强烈建议您查看Scala http://scala-lang.org。与使用 Java 相比，使用 Ruby 远没有那么痛苦（而且实际上在不同方面有很多乐趣）。你可以“保留”你认为理所当然的东西——基于表达式的语法、闭包、在许多地方省略类型的能力（不像 Ruby 那样开放，但你确实可以进行编译时类型检查；-）， everything(*)-is-an-object OO、统一的访问器方法、轻松构建 DSL 的能力以及糖——并获得静态类型语言的优势，包括本地类型推断、模式匹配、相对丰富的集合框架以及与 Java 的良好集成（包括众多的 Web 框架，还有一些利用 Scala 语言的特定于 Scala 的框架）。

C#3.0/4.0（和.NET3.5+）不是太破旧了要么（但避免 C#2.0，现在希望它已成为历史），并引入 LINQ/闭包、基本类型推断和其他 良好的语言特性 我发现它对于大多数任务来说“可以接受”（猜猜我如何评价 Java 作为一种语言；-）。然而，C# 是一种 CLR 目标语言（有/曾经有一个 .NET Scala 端口，但我不确定状态——尽管它不是主要目标平台）。

既然我提到了 Scala，我还应该提到 F#（现在是“官方”.NET 语言），它采用与 OCaml 类似的“面向对象的函数式”方法——Scala 则恰恰相反，我将其描述为“OO”与功能”。我听说过在类型系统方面支持/反对 F# 与 C# 的争论，但没有 F# 的实际经验。您可能喜欢也可能不喜欢这种范式转变。

快乐编码。