厌倦了非语义测试来弥补动态类型-建议吗? [英] Tired of non-semantic testing to make up for dynamic typing - suggestions?

问题描述

在我开始研究计算机工程之前，我曾经在Rails(之前的PHP)中做过很多Web编程.

I used to do a lot of web programming in Rails (PHP before that) before I started studying computer engineering.

从那时起，我在C语言方面做了大量的功课，并在Objective-C中完成了一些个人工作(Mac方面的工作).我学会了喜欢静态打字.

Since then, I've done a lot of school work in C, and some personal stuff in Objective-C (Mac stuff). I learnt to love static typing.

但是现在我必须进行一些专业的Web开发(自由职业)，并且再次选择了Rails.我发现编写非语义类型检查测试确实很烦人.我从C和Objective-C编译器中免费获得了这些代码.我喜欢点击Build，让系统检查我的所有代码，以确保A可以调用B，B可以调用一些晦涩的库C，等等.我要做的只是测试语义.但是使用Rails，我是编译器. :(

But now I'm having to do some professional web development (freelancing) and have picked up Rails once again. I'm finding it really annoying to write non-semantic type-checking tests. I was getting those for free from C and Objective-C compilers. I loved hitting Build and having the system check all my code to see that A can call B, B can call some obscure library C, etc. All I had to do was test the semantics. But with Rails, I'm the compiler. :(

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

Has anyone treaded this same path? Are my only options for web development ASP.NET MVC with C# and Java + x framework? Looking for some suggestions, or even some sympathy... :P

顺便说一句，我特别提到了Rails而不是Ruby，因为我不介意Ruby的动态特性(例如脚本或其他东西).但是，由于Rails依赖于如此多的宝石，并且由于一个宝石通常会添加许多其他宝石，因此动态类型化成为一个问题.

By the way, I make a specific reference to Rails rather than Ruby because I don't mind Ruby's dynamic nature for simple stuff like scripting or what not. But since Rails depends on so many gems and since one usually adds a number of other gems, the dynamic typing becomes an issue.

谢谢！

我遵循了pst的建议，并调查了Scala.在阅读该语言的创建者Martin Odersky撰写的《 Scala中的编程》一书时，我发现了这段文字，以许多方式表达了我的关注，甚至更多.非常有趣的阅读.

I followed up on pst's suggestion and looked into Scala. In reading the book Programming in Scala, written by the language's creator, Martin Odersky, I came accross this bit of text that in many ways expresses my concerns and a bit more. Very interesting reading.

摘自Martin Odersky在Scala中编程的第52页:

Taken from page 52 of Martin Odersky's Programming in Scala:

Scala是静态键入的

静态类型系统分类 变量和表达式根据 他们持有的价值观的种类和 计算. Scala脱颖而出 具有非常高级的静态语言 类型系统.从一个系统开始 嵌套类类型非常类似于Java， 它允许您参数化类型 与泛型结合使用 交集，并隐藏 使用抽象类型的类型.这些给 坚固的建筑基础 编写自己的类型，以便您 可以设计位于 同时安全，灵活地使用.

A static type system classifies variables and expressions according to the kinds of values they hold and compute. Scala stands out as a language with a very advanced static type system. Starting from a system of nested class types much like Java’s, it allows you to parameterize types with generics, to combine types using intersections, and to hide details of types using abstract types. These give a strong foundation for building and composing your own types, so that you can design interfaces that are at the same time safe and flexible to use.

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

If you like dynamic languages such as Perl, Python, Ruby, or Groovy, you might find it a bit strange that Scala’s static type system is listed as one of its strong points. After all, the absence of a static type system has been cited by some as a major advantage of dynamic languages. The most common arguments against static types are that they make programs too verbose, prevent programmers from expressing themselves as they wish, and make impossible certain patterns of dynamic modifications of software systems.

但是，这些论点常常不 违背静态类型的想法 一般，但针对特定类型 系统，也被认为是 冗长或太不灵活.为了 例如，艾伦·凯(Alan Kay)，发明者 Smalltalk语言，曾经评论过: 我不反对类型，但我不反对 知道不是 完全痛苦，所以我仍然喜欢动感 打字."

However, often these arguments do not go against the idea of static types in general, but against specific type systems, which are perceived to be too verbose or too inflexible. For instance, Alan Kay, the inventor of the Smalltalk language, once remarked: "I’m not against types, but I don’t know of any type systemsthat aren’t a complete pain, so I still like dynamic typing."

我们希望在这本书中说服您 Scala的类型系统离 成为完全痛苦".实际上， 很好地解决了通常的两个问题 有关静态类型的问题: 通过类型避免冗长 获得推理和灵活性 通过模式匹配和几个 编写和编写类型的新方法. 克服了这些障碍， 静态类型的经典好处 系统可以得到更好的理解. 其中最重要的 好处是 程序抽象，安全 重构，更好 文档.

We hope to convince you in this book that Scala’s type system is far from being a "complete pain." In fact, it addresses nicely two of the usual concerns about static typing: verbosity is avoided through type inference and flexibility is gained through pattern matching and several new ways to write and compose types. With these impediments out of the way, the classical benefits of static type systems can be better appreciated. Among the most important of these benefits are verifiable properties of program abstractions, safe refactorings, and better documentation.

可验证的属性

静态类型系统可以证明 没有某些运行时错误. 例如，他们可以证明 像这样的属性:布尔永远不会 加到整数;私人变量 不能从他们的外部访问 班级;功能适用于 正确数量的论点；只要 字符串曾经被添加到一组 字符串.

Static type systems can prove the absence of certain run-time errors. For instance, they can prove properties like: booleans are never added to integers; private variables are not accessed from outside their class; functions are applied to the right number of arguments; only strings are ever added to a set of strings.

未检测到其他类型的错误 当今的静态类型系统.为了 例如，他们通常不会检测 非终止函数，数组 违反界限，或除以 零.他们也不会检测到 您的程序不符合 规格(假设有一个 规格！).静态系统 因此被一些人解雇了 因为不是很有用争论 之所以这样，是因为这类系统可以 仅检测简单的错误，而 单元测试提供了更广泛的 覆盖率，为什么还要烦恼静态类型 完全没有?

Other kinds of errors are not detected by today’s static type systems. For instance, they will usually not detect non-terminating functions, array bounds violations, or divisions by zero. They will also not detect that your program does not conform to its specification (assuming there is a spec, that is!). Static type systems have therefore been dismissed by some as not being very useful. The argument goes that since such type systems can only detect simple errors, whereas unit tests provide more extensive coverage, why bother with static types at all?

我们相信这些论点会遗漏 重点. 尽管是静态类型 系统当然不能更换单元 测试，它可以减少数量 需要注意的单元测试 否则会有些特性 需要测试.同样，单元 测试不能替代静态类型. 毕竟，正如Edsger Dijkstra所说， 测试只能证明存在 错误，从来没有他们的缺席.所以 保证静态类型给 可能很简单，但它们是真实的 没有形式的保证 测试可以实现.

We believe that these arguments miss the point. Although a static type system certainly cannot replace unit testing, it can reduce the number of unit tests needed by taking care of some properties that would otherwise need to be tested. Likewise, unit testing cannot replace static typing. After all, as Edsger Dijkstra said, testing can only prove the presence of errors, never their absence. So the guarantees that static typing gives may be simple, but they are real guarantees of a form no amount of testing can deliver.

安全重构

静态类型系统提供了 安全网，让您进行更改 到高度的代码库 信心.例如考虑一个 重构增加了一个额外的 方法的参数.在静态 您可以进行打字的语言更改， 重新编译您的系统并简单地修复 导致类型错误的所有行. 完成此操作后，您将 一定要找到所有的地方 需要改变.同样适用于 许多其他简单的重构，例如 更改方法名称或移动 从一类到另一类的方法.在 在所有情况下，静态类型检查都会 为新产品提供足够的保证 系统的工作方式与旧版本一样.

A static type system provides a safety net that lets you make changes to a codebase with a high degree of confidence. Consider for instance a refactoring that adds an additional parameter to a method. In a statically typed language you can do the change, re-compile your system and simply fix all lines that cause a type error. Once you have finished with this, you are sure to have found all places that need to be changed. The same holds for many other simple refactorings like changing a method name, or moving methods from one class to another. In all cases a static type check will provide enough assurance that the new system works just like the old.

文档

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

Static types are program documentation that is checked by the compiler for correctness. Unlike a normal comment, a type annotation can never be out of date (at least not if the source file that contains it has recently passed a compiler). Furthermore, compilers and integrated development environments can make use of type annotations to provide better context help. For instance, an integrated development environment can display all the members available for a selection by determining the static type of the expression on which the selection is made and looking up all members of that type.

推荐答案

这是我关于动态语言的抓手"之一.我要测试语义，而不是类型错误；-)话虽如此，一个好的测试框架/设置实际上在所有非平凡的情况下都是必须的，并且良好的代码覆盖率和经过测试的需求很重要.

This is one of my "gripes" about dynamic languages. I want to test for semantics, not type errors ;-) That being said, a good testing framework/setup is really a must in all non-trivial situations and good code-coverage and tested requirements is/are important.

如果您确实想沿着JVM上的静态类型路径前进(我有)，我强烈建议您查看 Scala .来自Ruby，与使用Java相比，它的痛苦(并且实际上以不同的方式带来了很多乐趣)要轻得多.您可以保留"您理所当然的东西-基于表达式的语法，闭包，可以在许多地方省略类型的功能(不像Ruby那样开放，但是您确实可以进行编译时类型检查;-)，一切都是对象OO，统一的访问器方法，轻松构造DSL的能力和优势-并获得具有本地类型推断，模式匹配，相对丰富的收集框架的静态类型语言的优势，以及与Java的良好集成(包括众多Web框架，还有一些Scala特定的框架也利用Scala语言).

If you do want to go down the static-typing path on the JVM (I have), I would highly recommend looking at Scala. Coming from Ruby, it's far less painful (and actually lots of fun in different ways) than going to Java. You get to "keep" the things you take for granted -- an expression-based syntax, closures, the ability to omit types in many places (not as open as Ruby, but you do get compile-time type checking ;-), everything(*)-is-an-object OO, unified accessor methods, ability to construct DSLs easily, and sugar -- and get the benefits of a statically typed language with local type inference, pattern matching, a relatively rich collection framework, and decent integration with Java (including the numerous web-frameworks, there are some Scala-specific frameworks as well which leverage the Scala language).

C#3.0/4.0(和.NET3.5 +)也不是太破旧(但请避免使用C#2.0，现在希望它是一个遗物).闭包，基本类型推断等 不错的语言功能我发现它对大多数任务都是可以接受的"(猜测一下我如何将Java视为一种语言；-).但是，C#是CLR目标语言(存在/曾经有.NET Scala端口，但是我不确定状态-它不是主要的目标平台).

C#3.0/4.0 (and .NET3.5+) isn't too shabby either (but avoid C#2.0, which is now hopefully a relic), with the introduction of LINQ/closures, basic type inference and other nice language features I find it "acceptable" for most tasks (take a guess how I would rate Java as a language ;-). However, C# is a CLR-target language (there is/was a .NET Scala port, but I am not sure of the status -- it is not the main target platform though).

由于我已经提到了Scala，所以我还应该提到F#(现在是一种官方" .NET语言)，它采用的"OO功能"方法类似于OCaml，Scala则相反，我将对其进行描述作为具有功能的OO".与C#w.r.t类型系统相比，我听说过针对F#的论点，但对F#没有实际经验.您可能会或可能不会喜欢范式转换.

Since I have mentioned Scala, I should also mention F# (now an "official" .NET language) which takes the "Functional with OO" approach being similar to OCaml -- Scala is more of the reverse and I would describe it as "OO with Functional". I have heard arguments for/against F# compared to C# w.r.t the type system, but have no practical experience with F#. You may or may not like the paradigm shift.

快乐的编码.

这篇关于厌倦了非语义测试来弥补动态类型-建议吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！