Jest中describe()与test()的区别及test()是否可以省略

核心结论 #

你的判断是错误的，test（别名it）是Jest的必要测试单元，不建议直接在describe回调内部写expect断言

为什么直接写在describe里看起来能运行？ #

Jest执行测试分为两个阶段：

1. 测试收集阶段：遍历所有describe回调，注册内部的test用例、beforeEach/afterEach等钩子函数，这个阶段会直接执行describe回调里的非注册类代码
2. 测试运行阶段：按顺序执行钩子、执行所有注册的test用例、收集断言结果

你直接写在describe里的expect是在收集阶段就执行了，没有被当做测试用例统计，只是刚好逻辑简单没有抛出错误，才让你误以为测试正常跑通了。你可以运行第一段无test的代码，看Jest输出会显示Tests: 0 total，等于根本没有执行任何有效测试用例。

带test的写法核心优势 #

• 测试结果可统计：所有test的执行结果都会被统计到测试报告中，符合本地校验、CI/CD流水线的测试通过率校验要求
• 钩子函数可正常生效：beforeAll/beforeEach/afterEach/afterAll等钩子只会作用于test用例，直接写在describe里的断言不会触发钩子，如果你有用例依赖准备、清理逻辑，直接写的断言会完全不符合预期，比如下面的示例：

const sum = require('./sum');
describe('test sum', () => {
  let num = 0;
  // 测试前给num赋值为1
  beforeEach(() => {
    num = 1;
  })

  // 直接写在describe里的断言：执行时beforeEach还没触发，num还是0，断言报错
  expect(sum(num, 2)).toBe(3); 

  test('adds 1 + 2 to equal 3', () => {
    // test内部会先执行beforeEach，num为1，断言正常通过
    expect(sum(num, 2)).toBe(3);
  });
});

• 用例隔离性强：每个test是独立的运行单元，单个用例断言失败不会阻断其他用例执行，排查问题效率更高；如果多个expect直接写在describe里，第一个报错后后面的代码都不会运行，你无法判断后续逻辑是否正常
• 测试报告可读性高：每个test的描述会清晰标注当前用例的测试点，报错时可以直接定位到具体测试场景，不用在一堆代码里找是哪条断言出了问题

内容的提问来源于stack exchange，提问作者astridx