一种旨在测试的编程语言

Question

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

例如,设计的编程语言使得单元测试是编码过程的非可选部分,或者更好的是编程语言,其中程序或多或少地从单元测试中推断出来.

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

面向对象编程怎么样？像依赖注入和模拟库这样的东西真的有助于TDD,这些实践不会因为成为语言设计的一部分而受益吗？我一直在寻找具有丰富元模型的语言,倾向于允许使用目标语言编写类似DSL的API.这些库是建立在这之上的,为什么不把这些东西放到语言本身？

我发现詹姆斯布莱克引用的博客文章非常好.

不久前,我反思了过去十年的测试习惯,并提出了一些有趣的观察:

• 我觉得有必要为我经常编写的代码编写测试.
• 与往常一样,这种需求受到环境限制的阻碍,所以我最终没有编写这些测试.

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

Answer 1

谷歌正在研究noop作为一种语言(基于Java的OOP),用于生成始终可测试的代码.

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

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

Answer 2

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

我对这个问题很难过,因为我不确定语言是否可以通过设计进行测试.测试通常是关于工具和静态分析,而不是关于语言设计.

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

根据这些标准,我知道三个:

• Eiffel,"契约式设计"鼓励您在代码中加入前置条件和后置条件,并对它们进行测试.我认为Eiffel是一种成功部署的语言.

• 球拍(以前称为PLT计划),其中一些有趣的研究正在进行合同和测试; 有趣的是,当测试失败时,语言不仅会告诉您合同被违反,而且还会识别出应该归咎于代码的哪一部分.有关更多信息,谷歌为罗比Findler和"责备".Racket是一种研究语言,但它是Scheme的扩展,它广泛用于小众语言.

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

除了这些语言之外,还有无数语言为定理证明提供了断言.其中许多语言的断言都无法以任何有效的方式测试(通用和存在量词会对你这样做).

Answer 3

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

Answer 4

不是我知道的,但最接近我的可能就是埃菲尔.它也适用于.NET

Answer 5

当我玩弄零按钮测试的概念时,自然会出现一种强制测试语言/ IDE类型.它只是一种玩具语言,但其中的想法就在其中:任何未被测试覆盖的行显示为黄色,任何未经测试的行的任何函数都可以被认为是不可运行的(尽管项目从未走得那么远) .

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

Answer 6

动态类型语言(Python,Ruby等)已经看到了我见过的一些最大和最好的测试套件.我对Python有更多的经验,所以我将专注于它,但几乎Python和Ruby的每个属性在其可测试性方面都是等价的,并且开源项目倾向于使用它来包含测试套件.

有许多实际项目的具体例子很大,很多人都使用过,并且有大量的测试套件,是测试软件的良好结果的实际例子,我最熟悉的是在Python中.但是,也许SQLite人员(C/C++)在构建整个开源世界中最全面的测试套件之一方面值得称道.

Python测试套件(像所有python应用程序代码一样)通常比我使用的任何其他语言更短,更容易编写和更容易阅读.然而,虽然我不认为特别是C/C++是一种非常容易编写测试的语言,而且更可能是开发人员对SQLite项目的热情和技术技能,以及需要能够信任他们的工作导致用C++编写一个大型,全面,有效的测试套件,而与C++语言本身无关.

因此,Python可以帮助您轻松编写应用程序,让您有时间编写测试,这就是全部.但是,C++缺乏帮助您编写测试的功能,并且需要更长时间才能在C++中构建相同的东西,但仍有一些开发人员提供技能和奉献精神,并且无论如何都会以任何时间和精力花费成本.

虽然语言中的某些功能可以在流行的编译和动态语言中正式保证代码覆盖,但范围非常有限,但我认为正确的方法是修复您的形式主义,而不是改变您的语言.问题不在于现实世界无法满足我对测试的正式要求,而是需要通过改变我们构建测试代码的正式定义的方式来解决现实世界中可实现的限制(代码覆盖率) , 例如).换句话说,我们的测试形式中的漏洞抽象是我们失败的东西,而不是真正的现有技术(C/C++).

测试绝对是这个过程的一个可选部分,就像Python中的所有东西一样,实际上很少被强加给你.但是,我认为,任何找到一种方法来强迫你写测试而不是鼓励这种良好行为的语言实际上是试图立法编码实践的一个例子,这必然会适得其反.

我并不坦率地理解如何以一种迫使你进行测试的方式来设计一种语言,而不会将语言变成一种完全无用的学术三部曲.像许多其他人一样,我发现一种语言在实际工作中的可用性比象牙塔的形式主义概念和可证明的正确性更重要.

另一方面,我发现释放开发人员编写大量测试并能够有效测试代码的最佳方法是从开发中消除意外的复杂性.我相信Python和Delphi是我最熟练的两种语言,它比商业和开源开发中广泛使用的其他语言更能减轻这种负担.由于额外的时间,我不必花费多少时间来查找编写我的主应用程序代码需要多少嘟嘟嘟嘟的页面,我现在发现我有半天的时间来测试正确性,可伸缩性,甚至是做一些跨平台测试.

不要问你能为你的形式主义做些什么,而是要求你的形式可以做些什么才能重新回到现实.