javascript - 为什么测试框架的语法如此奇怪？

Question

我最近开始研究不同的单元测试解决方案(在 JavaScript 中，但我想我的问题不是特定于语言的)。

我想知道的主要问题是为什么试图模仿人类语言的语法如此奇怪？背后的原因是什么？

例如，来自 Chai 的示例断言库:

expect(obj).to.have.property('foo');

在我看来，使用语言的原生方式来表达同样的事情要清楚得多:

assert(typeof obj.foo != 'undefined');

这对我作为开发人员来说更具可读性，因为我已经知道如何 !=和typeof工作，并且无需阅读一些额外的 API 文档来调查到底是什么 .to.have.property()意思是。

目前我的印象是该语法可能来自 BDD/TDD 等最佳实践，并且有一种奇怪的感觉，即该想法在某种程度上接近 SQL 语法之外的内容。

在我看来，与其提供一组 10 个不同的函数来以最优选的语法执行相同的操作，不如拥有一组最小的测试特定函数会更简单、更方便，例如:

• 测试一个值(value)观是否真实；
• 比较两个数字/字符串/对象，如果不匹配，则另外显示差异；
• 检查值是否超出限制；
• ...

我错过了什么重要的事情吗？这是否意味着测试应该由可能不是程序员的产品负责人部分创建/评估？语法只是编写测试的某种传统吗？

Answer 1

我认为你是对的，很多框架都是从这样的想法演变而来的:你不需要成为一名程序员来理解测试涵盖的内容(因此，在测试优先的方法中，软件应该做什么)。

例如，查看 Cucumber 如何BDD测试框架描述了他们的系统:

Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.

A piece by Martin Fowler Cucumber 页面引用了 2008 年的内容，并提供了制作非 native 特定领域语言 (DSL) 进行测试的大概理由:

If business people are able to look at the DSL code and understand it, then we can build a deep and rich communication channel between software development and the underlying domain.

总而言之，我还没有看到或成为一个团队的一员，其中测试语言(通常将这种语法称为 DSL 是一种延伸)实际上被软件开发人员和“业务人员”使用，但也许在某些环境中这种情况更为常见。好消息是，大多数常见的测试框架都足够灵活，可以支持使用您喜欢的任何语法进行测试，包括您自己喜欢的 native /惯用方言，因此您可以自由地避开看似常见的 this.should 做法.be.equal.to.that 并只需说 assert(this === that)。