使用高度抽象的 DSL 来减轻测试负担?

  • Sadek Drobi
  • 李剑

2007 年 10 月 19 日

话题:敏捷架构语言 & 开发文化 & 方法

用户界面和用户期待,也即用户模型之间的不一致性,是 bug 的一个重要来源。如果没有面面俱到的信息来描述软件的工作方式,那么用户就会觉得它的行为是不可预知的。Leonardo Vernazzade 的观点是,用户和 UI 所使用的并不是同一种语言,所以需要进行翻译。

他在自己最近的 blog 上说到,“语言之间的差异越大,翻译时出现的问题也会越多”,同时,为了保证翻译的一致性而带来的测试压力也就越大。所以,在很多 情况下,比较好的解决方式就是提供一个用户模型和用户界面可以共享的“高度抽象的语言”,也就是领域特定语言(DSL)。这可以帮助我们避免翻译和相应的 测试所造成的浪费。Leonardo 认为,从更通用的角度来说,提高抽象级别可以减轻测试负担,而且这一做法可以被应用到任何其他模型中,如软件设计、实 现等等: 

当你站在合适的抽象层次上表达一些事情的时候,就无需测试了,[……] 你会对 C# 或者 Java 中的 += 运算符进行测试么?反正我不会。

Andres Aguiar 也曾经在他的 blog 上谈论说,如果我们在完善抽象这一方面投入足够的精力,那么就没有必要进行 TDD,甚至是单元测试了。但还是有一些问题是需要考虑周全的。

使用 DSL 来减轻测试的负担,其前提就是要对 DSL 本身进行彻底的测试。Leonardo Vernazza 声称,“在大多数情况下,这比测试所有的用户界面要简单的多,而且工作量也会大大减少”。这种方法会带来“责任的再分配”,把测试的负担转移到 DSL 的作者身上。不过 Gareth Jones 相信,“很多 DSL 的作者都不会用大量的语言变量来测试他们的代码生成器”。

Scott Bellware 在Andres Aguiar 的帖子后面着重说到, 判断“抽象所固有的最佳层次”并非易事,但 Brad Head 指出,这正好就是 TTD 所做的事情:“用‘试试看’来挑战你的设计抽象”。然而 Ron Scott 却争论说,TDD 是用来找出代码中的变化是否造成了破坏的手段。Bellware 实际上所强调的是,如果一个经过设计优化的 DSL“功能上已经 全部完成,不再变化”,那么要是想通过关注业务或是技术领域来推进 DSL 的发展的话,那它就无法再像从前一样为我们带来同样的价值。

您是怎样看待抽象 vs. 测试的呢?你认为可以用 DSL 来减轻测试的负担么?

查看英文原文High abstraction level of DSLs to reduce the testing burden?

敏捷架构语言 & 开发文化 & 方法