用户界面和用户期待，也即用户模型之间的不一致性，是 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?
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论