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

Question

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

从那时起，我就完成了很多C方面的学习工作，并在Objective-C中做了一些个人工作(Mac方面)。我学会了喜欢静态打字。

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

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

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

谢谢!

编辑:

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

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

Scala is statically typed

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.

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.

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.”

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.

Verifiable properties

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?

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.

Safe refactorings

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.

Documentation

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.

Answer 1

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

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

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

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

快乐的编码。