一种旨在测试的编程语言

Question

是否存在可以通过设计测试的编程语言，或者至少在可测试性方面表现出非常好的属性？

例如，一种编程语言，旨在使单元测试成为编码过程的非可选部分，或者更好的是编程语言，其中程序或多或少地从单元测试中推断出来。

或者如果您更喜欢扭曲问题，那么命令性编程是不好的做法还是不必要的以确保可测性？

面向对象编程怎么样？像dependency injection和模拟图书馆这样的东西确实有帮助TDD，这些实践不会因为参与语言设计而受益吗？我一直在环顾四周，具有丰富元模型的语言倾向于允许非常DSL - 类似API以目标语言编写。这些库是建立在这个基础之上的，为什么不把这些东西放到语言本身？

我发现James Black引用的blog post非常有意义。

  

不久前，我反思过我   过去十年的测试习惯，   我做了几个有趣的事情   观察：

     

  
• 我觉得有必要为我经常编写的代码编写测试。
  
• 同样经常，这种需求受到环境限制的阻碍，所以我结束了   不写这些测试。
  

您是否同意动态编程语言使编写测试更容易的说法？

Answer 1

Google正在开发noop作为一种语言（基于Java的OOP），用于生成始终可测试的代码。

  

Noop是一种将在Java虚拟机上运行的新语言，源代码形式与Java类似。目标是从一开始就将依赖注入和可测试性构建到语言中，而不是像其他语言那样依赖第三方库。

该语言还明确禁止使某些结构更难以测试代码，例如静态。

Answer 2

  

哪些编程语言可以通过设计进行测试？

我在这个问题上遇到了困难，因为我不确定语言是否可以通过设计进行测试。测试通常是关于工具和静态分析，而不是关于语言设计。

但是，如果语言可以测试，我将假设这意味着该语言包含某种可以针对代码进行测试的独立规范，而且这些规范的设计考虑了测试，或者至少不仅仅用于定理证明。

按这些标准， 我知道三个：

• Eiffel，其中“按合同设计”鼓励您在代码中添加前置条件和后置条件，并对其进行测试。我认为Eiffel是一种成功部署的语言。

• Racket（原PLT计划），合同和测试正在进行一些有趣的研究;有趣的是，当测试失败时，语言不仅会告诉您合同被违反，而且还会识别出应该责怪代码的哪一部分。有关更多信息，谷歌为罗比Findler和“责备”。 Racket是一种研究语言，但它是Scheme的扩展，它广泛用于小众语言。

• Ana，由David Luckham及其学生完成的Ada扩展，支持一些测试。据我所知，Ana从未超越研究阶段。

除了这些语言之外，还有无数种语言为定理证明提供了断言。其中许多语言的断言都无法以任何有效的方式进行测试（通用和存在量词会对你做到这一点）。

Answer 3

像Haskell这样的纯函数式语言可能是一个很好的候选者，因为在这样的语言中，函数没有副作用，并且在给定相同输入的情况下总是产生相同的结果。

Answer 4

不是我知道的，但我最接近的可能是Eiffel。它也适用于.NET

Answer 5

当我使用Zero Button Testing的概念时，自然会出现强制测试语言/ IDE类型。它只是一种玩具语言，但其中的想法就在其中：任何未被测试覆盖的行显示为黄色，任何未经测试的行的任何函数都可以被认为是不可运行的（尽管项目从未走得那么远）

这里的想法是测试直接建立在他们正在测试的程序中;它在这种规模下工作，但我对该方法的最终可扩展性存在疑问。

Answer 6

Answer 7

Maude可能是一个极端的例子：每个程序都是代数重写逻辑中的一个理论，并且可以直接受建设性证明。

Answer 8

我从来没有见过任何测试是非可选的，内置的或推断的，但我见过的最“暴躁”的语言是Ruby - 它带有开箱即用的单元测试工具，它很容易测试和模拟，因为类型是动态的，社区通常很好地进行测试实践（有许多TDD和BDD工具可用）。虽然我注意到奇怪的代码覆盖工具缺乏。

Answer 9

具有design by contract的语言，例如Eiffel（或Java中的iContract）可能是个好主意。这样，您可以非常轻松地测试前置和后置条件以及类不变量。

除此之外，TDD在很大程度上与语言无关。

Answer 10

Spring Framework围绕依赖注入和创建易于测试的普通旧Java对象（PO​​JO）

Answer 11

Fortress似乎旨在内置更多的单元测试功能，但是，根据此博客，D也可以设计为使单元测试成为您班级的一部分。

http://beust.com/weblog2/archives/000522.html

<强>更新

上面引用的博客涉及此帖的问题，标题是：

编程语言应该支持本机单元测试吗？

所以有关于测试的其他语言的评论。

Answer 12

我认为Ruby就是它的所在。

cucumber之类的工具 - 用几乎自然语言编写用户故事，商业人士可以理解然后实际让他们通过这些故事作为“TDD工具”非常棒。

这不是关于编写“测试”，而是从客户想要的东西开始，并使用工具将其作为您的规范来构建。

除了rspec之外，shoula，机械师，骗子和其他人如果这是你感兴趣的地方，那么Ruby应该是一个真正的考虑因素。

我还要说创建自己的DSL的能力将动态语言放在这个领域的前面。

Answer 13

我也会将Erlang加入到环中，遵循许多关于函数式语言的注释。规范扩展支持合同的编译时验证，EUnit非常出色。

此外，像守卫模式这样的策略是表达你的状态机意图的整体语言结构，并在你违反这个意图时断言。

Answer 14

诺普接受的答案现在已经死了。 Wake是一种新语言，具有许多相同的目标（例如可测试性），目前仍在开发中，但现在可以更好地回答这个问题。