当我们在编写前端自动化测试代码时，我们经常会用到断言(assertions)。在 JavaScript 生态中，有很多流行的测试框架，比如 Mocha、Jasmine、AVA 等，其中最为流行的是 Mocha。而在 Mocha 流行的测试框架之中，最常用的是 Chai，这是一个流行的断言库，可以用来进行 TDD（测试驱动开发）、BDD（行为驱动开发）等软件开发方式。不过，Chai 还有不同的断言模式，其中两种比较常用的模式是 should 断言和 expect 断言。本文将介绍这两种断言的区别，并为您提供适用的情况和实际示例代码，以及一些学习和指导意义。
should 断言
should 是一种 BDD 风格的断言库，它的语法很像自然语言的语法，可以让我们编写出非常易读的代码。
如何使用 should 呢？只需在项目中引入 chai 库中的 should 模块即可：
const should = require('chai').should();
有了 should 模块，我们就可以将其添加到断言链中进行断言：
const foo = 'bar'; foo.should.be.a('string');
断言的语义是“foo 应该是一个字符串”。如果 foo 不是字符串，则测试用例将失败并将出现错误消息。如果 foo 是一个字符串，则测试用例将通过。
我们也可以将多个断言链接在一起：
const foo = 'bar'; foo.should.be.a('string').and.not.empty;
上面的这个断言首先验证 foo 是一个字符串，然后验证它不是一个空字符串。
expect 断言
expect 断言采用了更加传统的风格，它的调用方式类似于函数：
const expect = require('chai').expect;
有了 expect 模块，我们硬生生地把要断言的对象传递给 expect 函数的参数中。再使用 to 方法，断言的语法是“expect(foo).to.be.a('string')”：
const foo = 'bar'; expect(foo).to.be.a('string');
这通过看起来更像是自然语言的方式实现了相同的测试。
当然，expect 断言也可以链接多个断言：
const foo = 'bar'; expect(foo).to.be.a('string').and.not.empty;
这个链接与 should 断言链非常相似，但是在这里我们使用不同的 API。
should 与 expect 的区别
由于 expect 断言从行为上更接近传统的测试断言，因此它更容易转换为其他测试框架或使用派生语言，如 TypeScript。
相反，should 断言映射到自然语言的方式更接近 BDD，使其更接近非技术利益相关者。
在实践中，两种风格在可读性和可组合性方面都很好。唯一的问题是，should 是一个函数；由于函数的原因，有时会在应用程序中创建一些麻烦。如果想要避免这方面的问题，可以使用 expect 断言。
示例代码
下面是一个例子，展示了 should 断言和 expect 断言之间的主要区别：
-- -------------------- ---- ------- ----- ------ - ------------------------- ----- ------ - ----------------------- -- -------- ----- ---- - -- ----- ---- - -- -- ------ ---- ------------------------ -- ------ ---- ---------------------------- -- -------- ----- ------ - --- -- ------ ---- -------------------------------- ----------------------------- ---------------------------- -- ------ ---- ------------------------------------ --------------------------------- --------------------------------展开代码
学习和指导意义
选择合适的断言风格：should 或 expect。如果您更喜欢在编写测试用例时撰写即类似自然语言的语法，可以选择 should 断言。如果您想要使用传统的测试断言行为，则应该使用 expect 断言。
必须清楚每个断言的值所代表的含义，以及为要进行断言的程序语言和架构选择合适的方式。这样才能更好地理解代码中的错误，并使代码更容易理解。
应始终注重代码的可读性和可组合性，以方便将来的使用和维护。应该在可读性和可组合性之间找到平衡，以优化测试代码和应用程序代码的逻辑。
控制代码的耦合性。单元测试应该是为了验证代码的正确性，而不是绑定到输入或输出上。不应编写依赖于应用程序内部的特定实现细节的测试。应该编写可以独立于应用程序执行的测试。\
代码覆盖率。不能仅单元测试而忘掉代码覆盖率。在运行测试之前，请确保应用程序已经覆盖到代码的所有部分。应该评估测试是否覆盖了代码的不同路径，包括正确和错误的流程，在有必要时应增加测试代码的覆盖率。
来源：JavaScript中文网 ，转载请注明来源 https://www.javascriptcn.com/post/67c9a723e46428fe9e161370
