在规范`expect`中复制Node.js`assert`断言

Question

与具有自定义开发人员友好检查的非断言代码相反,

class Some {
  constructor(arg) {
    if (Array.isArray(arg) && arg[0] === 'foo')
      this.foobar = arg.concat('bar').join('');
    else
      console.error('Bad Some constructor arg');
  }
}

目前经过测试的代码充满了Node assert断言和相当有意义的message参数:

class Some {
  constructor(arg) {
    assert.deepEqual(arg, ['foo'], 'Some constructor arg');
    this.foobar = arg.concat('bar').join('');
  }
}

断言就在那里

• 保持代码平坦和可读
• 通过调用堆栈提供有关错误使用的有意义反馈
• 阻止函数执行,不要进一步传播错误
• 抛出错误并将错误处理留给调用者

目前的规格可能如下:

it('...', () => {
  let some = new Some(['foo']);
  expect(some).to...

它将通过 - 在规范中声明了所需的用法,它在测试代码中声明了不合需要的用法.

要部分重叠代码断言,它可能是偶数

it('...', () => {
  const { AssertionError } = require('assert');
  let some = new Some(['foo']);
  expect(some).to...
  expect(() => new Some(['bar']).to.throw(AssertionError);

所以我们在这里基本上假设一半的测试工作已经在代码本身中完成assert并跳过细节(to.not.throw并匹配AssertionError消息).

上面的例子使用了Mocha + Chai,但同样的事情适用于Jasmine.

• app断言应该被视为任何其他代码行,并且使用spec断言加倍(抛出,不抛出,AssertionError消息匹配),采取快捷方式的后果是什么？

• 可以测试覆盖率工具(伊斯坦布尔)assert除了考虑应用程序代码中的断言expect吗？

• 可能测试跑步者会被应用程序混淆,而不是规范断言引发错误？

成功的开源JS项目的一些例子在实践中证明或反驳"断言断言断言"也可能有所帮助.

Answer 1

如果应用程序断言被视为任何其他代码行并与规范断言加倍（抛出、不抛出、AssertionError 消息匹配），那么采取捷径的后果是什么？

应用程序断言是为了通知开发人员错误地使用了某段代码，理想情况下它们永远不会在生产中发生。如果确实发生了，那么它们将作为一种工具来识别出了什么问题，就像标准错误一样。但理想情况下，它们是开发过程中的第一道防线，并且只应该在那时发生。（因此，这就是为什么在某些语言中您可以一起禁用运行时断言的原因之一）

如果您编写一些使用断言来确保输入参数经过验证或程序的使用不会不一致的类，那么将该逻辑置于单元测试下肯定也很有意义。如果您要在某个时候更改断言，您希望能够测试您不会破坏其他人的代码。

除了预期之外，测试覆盖率工具（伊斯坦布尔）是否还可以考虑应用程序代码中的断言断言？

是的。如果您设置一个单元测试来触发断言，然后在 chai 中捕获它，那么该代码路径将显示在您的覆盖率报告中。这与任何其他代码路径没有什么不同，除非我误解了你的问题。

测试运行者可能会对引发错误的是应用程序而不是规范断言这一事实​​感到困惑吗？

当您使用该模块编写断言时assert，它会抛出一个AssertionError. 这是模块AssertionError中的类assert。当 chai 抛出错误时，它也会抛出一个AssertionError，但这将是来自 chai 模块的完全不同的类，它们只共享名称。因此，对于断言的来源不应该有任何混淆。
通常，您根本不会通过 try / catch 构造捕获测试代码中的断言，因此这实际上不应该成为问题。

通常断言测试的状态比单元测试简单得多。但是断言结束和单元测试应该开始的地方确实没有正式定义。更多阅读：

https://softwareengineering.stackexchange.com/questions/18288/are-asserts-or-unit-tests-more-important