厌倦了非语义测试以弥补动态键入 - 建议？

Question

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

从那时起，我在C中做了很多学校工作，以及Objective-C（Mac的东西）中的一些个人工作。我学会了喜欢静态打字。

但是现在我必须进行一些专业的网络开发（自由职业），并再次捡起了铁路。我发现编写非语义类型检查测试真的很烦人。我从C和Objective-C编译器中免费获得了这些。我喜欢击中构建，并让系统检查我的所有代码，以查看A可以调用B，B可以调用一些晦涩的库C等。我要做的只是测试语义。但是有了铁轨，我是编译器。 :(

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

顺便说一句，我对轨道而不是红宝石进行了特定的引用，因为我不介意Ruby的动态性质，例如脚本或没有什么。但是，由于铁轨取决于许多宝石，并且由于通常会添加许多其他宝石，因此动态键入成为一个问题。

谢谢！

编辑：

我跟进了PST的建议，并研究了Scala。在阅读由语言的创建者马丁·奥德斯基（Martin Odersky）撰写的Scala编程中，我来了这片文字，从许多方面来说，我的关注点和更多。非常有趣的阅读。

取自马丁·奥德斯基（Martin Odersky）在斯卡拉（Scala）编程的第52页：

Scala在静态上打字

静态类型系统根据其持有和计算的值类型对变量和表达式进行分类。 Scala是一种具有非常高级的静态类型系统的语言。从像Java一样的嵌套类类型系统开始，它允许您使用仿制药对类型进行参数化，从而使用交叉点组合类型，并使用抽象类型隐藏类型的详细信息。这些为建造和组成自己的类型奠定了坚实的基础，因此您可以安全地设计安全且灵活地使用的界面。

如果您喜欢诸如Perl，Python，Ruby或Groovy之类的动态语言，您可能会发现Scala的静态类型系统被列为其强调点之一有点奇怪。毕竟，没有静态类型系统被某些人引用为动态语言的主要优势。反对静态类型的最常见论据是，它们使程序过于冗长，防止程序员按照自己的意愿表达自己，并使某些动态修改的软件系统模式不可能。

但是，这些论点通常不违背静态类型的想法，而是针对特定类型的系统，而特定类型的系统被认为是冗长或太僵化的。例如，SmallTalk语言的发明者Alan Kay曾经说过：“我不反对类型，但我不知道有任何类型的系统，这不是完全痛苦，所以我仍然喜欢动态打字。”

我们希望在这本书中说服您，Scala的类型系统远非“完全痛苦”。实际上，它很好地解决了关于静态键入的两个常见问题：通过类型推理和灵活性通过模式匹配和几种新的编写和撰写类型来避免使用灵活性。由于这些障碍，可以更好地理解静态类型系统的经典优势。这些好处中最重要的是程序抽象的可验证属性，安全的重构和更好的文档。

可验证的属性

静态类型系统可以证明没有某些运行时错误。例如，它们可以证明属性：布尔值永远不会添加到整数中；私人变量无法从他们的班级外访问；功能应用于正确数量的参数；只有字符串添加到一组字符串中。

当今的静态类型系统未检测到其他类型的错误。例如，他们通常不会检测到非终止功能，数组界限或分为零。他们还不会检测到您的程序不符合其规范（假设有规格，即！）。因此，静态类型系统已被某些人驳回，因为它不是很有用。论点是，由于这种类型的系统只能检测到简单的错误，而单位测试提供了更广泛的覆盖范围，为什么还要打扰静态类型呢？

我们认为这些论点错过了重点。 尽管静态类型系统肯定无法替代单元测试，但它可以通过照顾一些否则需要测试的属性来减少所需的单位测试数量。 同样，单元测试不能替代静态键入。毕竟，正如埃德斯格·迪克斯特（Edsger Dijkstra）所说，测试只能证明存在错误，从来没有任何错误。因此，保证静态打字可能很简单，但是它们确实保证了一种表格，无法提供任何测试。

安全的重构

静态类型系统提供了一个安全网，可让您高度信心对代码库进行更改。例如，考虑一个重构，将其他参数添加到方法中。在静态类型的语言中，您可以进行更改，重新编译您的系统，并简单地修复引起类型错误的所有行。完成此操作后，您一定会找到所有需要更改的地方。对于许多其他简单的重构，例如更改方法名称或将方法从一个类移动到另一个类别。在所有情况下，静态检查都将提供足够的保证，即新系统像旧系统一样工作。

文档

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

Answer 1

这是我关于动态语言的“抓地力”之一。我想测试语义，而不是键入错误;-)说，在所有非平凡情况下，良好的测试框架/设置确实是必须的，良好的代码覆盖和测试要求很重要。

如果您想沿着JVM上的静态型路径走（我有），我强烈建议您查看 Scala. 。来自Ruby，它比去Java的痛苦要小得多（实际上以不同的方式有趣）。您可以“保留”您理所当然的事情 - 基于表达的语法，闭合，在许多地方忽略类型的能力（不像Ruby那样开放，但您确实会得到编译时类型的检查;-)，），：所有内容（*） - iS-An-Object OO，统一的访问者方法，轻松构造DSL以及糖的能力 - 并获得具有本地类型推理，模式匹配，相对丰富的收集框架和相对丰富的静态类型语言的好处与Java的体面集成（包括众多的Web-FrameWorks，还有一些特定于Scala的框架，可以利用Scala语言）。

C＃3.0/4.0（和.net3.5+）不是 太破旧了 要么（但要避免C＃2.0，这是希望现在是遗物的），随着Linq/Closures的引入，基本类型推理和其他不错的语言功能，我对大多数任务都“可接受”（请猜测我将如何评价Java评分Java作为一种语言;-)。但是，C＃是一种CLR-TARGET语言（有/是.NET Scala端口，但我不确定状态 - 虽然不是主要目标平台）。

由于我已经提到了Scala，因此我还应该提到F＃（现在是“官方” .NET语言），它采用“使用OO”方法与OCAML相似 - Scala更相反，我将其描述为“ OO具有功能性”。与C＃WRT类型系统相比，我听到了针对/反对F＃的争论，但对F＃没有实践经验。您可能喜欢也可能不喜欢范式偏移。

愉快的编码。

Answer 2

正如您提到的铁轨，并且鉴于您对Scala感兴趣，您绝对应该检查 电梯. 。这是一个 2008访谈 与它的创造者和一个 2009演讲 （视频），我链接的是因为尽管旧，但它们将升力与其他语言的替代品进行了比较。

但是，如果不是您的事，请放心 其他Scala Web框架.

Answer 3

这种类型的测试通常不在导轨中进行。不必为此而感到烦恼，而不必担心它。或者也许可以更好地解释为什么您认为这是一个问题，因为大多数Rails程序员没有。

更新

写作的人 test_include_with_order_works 在此特定情况下，确保铁轨将解释与字符串相同的符号。这似乎不是您必须测试的，因为Rails已经为您提供并测试了此功能。坦白说，我有些惊讶的是，任何人甚至都会担心符号是否会像字符串一样起作用。我们都知道它可以并且经常做。

通常，我认为铁轨框架必须确保您不做的事情，以使其实施将符合其设计。我相信动态键入语言的工作理念是，客户端代码不会传递会破坏他们所调用的方法的参数。如果他们这样做，他们将没有用来调用这些方法。您不必浪费时间确保在提供太多参数时您的方法会引发异常，而当您的方法可以轻松（并且应该）忽略额外的参数时。

因此，我不确定您提供的示例是否真的表明需要在铁轨中进行非语义测试。